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„Die wichtigsten Innovationen sind jene, die das Denken verändern.“ Diesen Anspruch 
stellen wir mit diesem Buch, dem Aphorismus von Hans-Jürgen Quadbeck-Seeger, 
einem deutschen Chemiker, folgend. Unsere Ingredienzen: 

„Verständlichkeit ist die Höflichkeit eines Experten.“ Auch hier haben wir versucht, 
unserem Aphorismengeber treu zu bleiben. Das Werk soll alle Interessierten begeistern 
können. Daher muss es verständlich sein. 

„Luxus: Kult um das Unnötige.“ Wir wollen alle jene ansprechen, die das Wesen von 
Prozessen und ihre Nutzbarkeit im praktischen Tun begreifen wollen, ohne intensive 
Sprach- und Gebrauchsstudien, vielmehr mit praxistauglichen Konzepten unterfüttert. 
Studierende mögen den Textbuchcharakter des Buchs schätzen, PraktikerInnen die Bei- 
spiele, ForscherInnen und EntwicklerInnen die Konzeptdarstellungen und Theorieaus- 
flüge. 

„Je größer das Projekt, desto stiller wird es begraben.“ Seit mehr als einem Jahr- 
zehnt gibt es das Konzept und auch das Projekt. Es huldigt Einfachheit und Überschau- 
barkeit, ohne komplexe Zusammenhänge zu vernachlässigen. Die Treiber des Projekts 
verspüren steten Aufbruch. Es ist also Zeit, die Digitalisierung von Prozessen aus der 
Brille der Subjektorientierung zu betrachten. 

„Abenteuertouristen zieht es zu Orten, wo sie nichts zu suchen haben.“ Der Blick 
lohnt sich, da sich eine Sicht auftut, die Nahe an unsere Wahrnehmung der Wirklich- 
keit kommt, Bestehendes schlüssig erweitert, und uns so neuen Handlungsspielraum 
verschafft. Auch unsere BegleiterInnen auf dem Weg zur Fertigstellung des Werks sind 
Abenteurer. Ihnen gebührt besonderer Dank: 


e Christoph Moser — mit seinen Einsichten zur organisationalen Praxis 
e Edith Rieß - sie hat uns geholfen, die Formatierung formschön zu gestalten 
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e Jerome Geyer-Klingeberg von Celonis SE — zur Verdeutlichung der Prozesspraxis 


„Innovationen sind keine Naturereignisse, wir müssen sie wollen und durchsetzen.“ — Ad 
multos multiplicatores, nicht nur in Ingolstadt, Pfaffenhofen, Steyr und Wien. 
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Werner Schmidt 
Christian Stary 
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Geschäftsprozesse helfen, Organisationen zu strukturieren und zu betreiben. Sie stel- 
len den Bezugsgegenstand von Geschäftsprozessmanagement dar und integrieren alle 
wesentlichen Elemente, um Anforderungen, welche an Organisationen gestellt werden, 
nachvollziehbar und strukturiert zu bearbeiten. Alle Beteiligten wissen somit, in welcher 
Form ihre Aufgaben zu bewältigen sind. Jedoch ist seitens der Stakeholder grundsätz- 
liches Verständnis zu den heutigen Rahmenbedingungen der Geschäftswelt sowie zu 
Unternehmensstrukturen und deren Repräsentation erforderlich. 


1.1 Geschäftsprozesse und Geschäftsprozessmanagement 


Es gibt keine Organisation ohne Prozesse. Wenn Menschen etwas gemeinsam tun wol- 
len, benutzen sie dafür die notwendigen Hilfsmittel und stimmen entsprechend dem 
gewünschten Ergebnis ihre Tätigkeiten aufeinander ab. Da solche Tätigkeiten nicht nur 
von Menschen ausgeführt werden können, sondern auch von Automaten und Computern 
müssen deren Aktivitäten in die Abstimmung ebenfalls einbezogen werden. Insbesondere 
in zumindest teilweise automatisierte Prozesse sind also verschiedene Typen von Han- 
delnden involviert. 

Ausgelöst wird ein Prozess durch ein Ereignis, das seinen Ursprung innerhalb 
oder außerhalb der Organisation haben kann wie etwa ein Dienstreiseantrag oder eine 
Kundenbestellung. Das abgestimmte und zielgerichtete Handeln als Reaktion auf ein sol- 
ches Ereignis wird als Prozess bezeichnet. Handelt es sich bei der Organisation um ein 
Unternehmen spricht man von Geschäftsprozessen. 

Es gibt kein Unternehmen ohne Geschäftsprozesse. Es gibt nur Unterschiede welchen 
Reifegrad diese haben. Die Reaktionen einer Organisation auf bestimmte Geschäfts- 
ereignisse können bei ihrem Auftreten immer von neuem abgestimmt werden oder 
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es wird eine Vorgehensweise festgelegt, die dann in solchen Fällen immer wieder aus- 
geführt wird. Ereignisse der gleichen Art wie beispielsweise Bestellungen werden als 
Ereignisklasse bezeichnet. Eine vorab festgelegte Vorgehensweise für eine Ereignis- 
klasse wird als ein Prozessmodell bezeichnet. Bei der Ausführung der im Modell fest- 
gelegten Tätigkeitsfolgen als Reaktion auf ein identifiziertes konkretes Ereignis, z. B. die 
Buchbestellung des Kunden Huber vom 20. Mai, handelt es sich um eine Prozessinstanz. 

Jedes Unternehmen hat unabhängig von seiner Art des Geschäfts bestimmte Standard- 
prozesse, die aber unternehmensindividuell ausgestaltet und zugeschnitten sein können. 
So verfügt beispielsweise jedes Unternehmen über einen Order-to-Cash-Prozess, mit 
dem es auf Geschäftsereignisse vom Kundenauftrag bis zum Zahlungseingang reagiert 
und diese durch Buchungen dokumentiert. Umgekehrt wird ein Beschaffungsprozess 
existieren mit Bestellungen zur Befriedigung eigener Bedarfe, dem konkreten Bezug 
(z. B. Wareneingang und Einlagerung) sowie der Bezahlung der Kreditoren. Weitere 
Beispiele sind Prozesse für die Personalbeschaffung oder die Logistik. Eine gebräuch- 
liche Klassifikation unterteilt Prozesse nach ihrem Charakter in Management-, Kern- und 
Supportprozesse. Die Einordnung ist unternehmensspezifisch und hängt u.a. von der 
Branche ab. 

Je klarer ein Unternehmen seine Geschäftsprozesse definiert und je konsequenter es 
diese im täglichen Geschehen umsetzt, umso leistungsfähiger ist es. Bei viele Unter- 
nehmen gründet ihre Wettbewerbsfähigkeit nicht (mehr) nur auf die Besonderheit ihrer 
Produkte, sondern auf die Güte der Geschäftsprozesse. Während beispielsweise das 
Geschäft eines Verlags in erster Linie durch seine Bücher bestimmt wird, bestimmt bei 
Amazon maßgeblich die Kundenerfahrung bei Suche, Auswahl, Kauf, Bezahlung, Lie- 
ferung und eventuelle Rückgabe von Produkten, also der reibungslose, kundenzentrierte 
Prozess den Erfolg. 

Die Modelle für solche Prozesse sind laufend anzupassen oder komplett neu zu 
gestalten, weil sich die Reaktionen auf eine Ereignisklasse ändern können bzw. zusätz- 
liche Reaktionen auf neue Ereignisklassen nötig werden. Die resultierenden Spezi- 
fikationen müssen außerdem in der Organisation und der IT-Infrastruktur umgesetzt 
werden, damit die Mitarbeiterinnen und Mitarbeiter im Tagesgeschäft Instanzen der 
Prozesse abarbeiten können. Dabei sind Rahmenbedingungen zu beachten wie die 
Effektivität, Effizienz und Compliance, also die Anforderungen, das gewünschte Ergeb- 
nis mit dem geringsten möglichen Ressourcenaufwand und unter Einhaltung gültiger 
externer und interner Regularien (z. B. Gesetzen) zu liefern. Für die Erledigung dieser 
Aufgaben hat sich das Geschäftsprozessmanagement (Business Process Management, 
BPM) etabliert. Es bezeichnet einen integrierten Managementansatz für Analyse, Design, 
Optimierung, Implementierung, Steuerung, Überwachung und Weiterentwicklung der 
Management-, Kern- und Supportprozesse im Unternehmen. In technischer Hinsicht 
schließt es auch die I[T-Unterstützung dieser Teilaufgaben durch Werkzeuge z. B. für die 
Modellierung oder Ausführung (z. B. Process Engines) oder umfassendere Business- 
Process-Management-Systeme (BPMS) ein. 
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Im Geschäftsprozessmanagement werden als Ausschnitt der Wirklichkeit ein Unter- 
nehmen und sein unmittelbares Umfeld betrachtet. In diesem Ausschnitt der Welt 
wünscht jemand eine Leistung von anderen in Form eines physischen Produkts, eines 
Service oder einer Kombination aus beidem. Die Leistung soll entsprechend den 
Anforderungen erbracht werden, der Wunsch nach ihr ist das Geschäftsereignis, auf das 
das Unternehmen nach seinen Vorstellungen im definierten Modell reagieren soll. 

Beim Geschäftsprozessmanagement gilt es also ein Modell der Leistungserstellung 
zu definieren und auf die Abwicklung von Geschäftsfällen anzuwenden. Dies bedeutet 
die Wirklichkeit gemäß Modell anzupassen, also betroffene Ausschnitte der Wirklich- 
keit zu analysieren und diese Wirklichkeit zu verändern. Da diese Wirklichkeit und 
die angestrebten Veränderungen sehr komplex sind, werden im BPM mehrere Modell- 
konzepte aus der Sozialwissenschaften, der Betriebswirtschaft und der Informatik 
zusammengeführt und kombiniert. 

In den folgenden Abschnitten umreißen wir eine Gesamtsicht auf das Prozess- 
management und erläutern diese dann in den weiteren Kapiteln im Detail. Ausgehend 
vom Blick der Beteiligten auf die Welt werden die vielfältigen Facetten des Geschäfts- 
prozessmanagements dargestellt und eine Auswahl von Modellen vorgestellt, die sich 
dabei in unserer Praxis bewährt haben. Die Gestaltung solcher Modelle unterstützt den 
Weg von einer mehr oder weniger unstrukturierten oder unbefriedigenden Arbeitsweise 
zu einer Prozessabwicklung, die den Vorstellungen des Unternehmens und seiner Kun- 
den entspricht. 

Die überblicksartige Gesamtsicht entwickeln wir schrittweise, ausgehend von indivi- 
duellen Perspektiven der Beteiligten auf ihre Arbeit in einem Prozess, deren Strukturie- 
rung und Harmonisierung über die Spezifikation in einem Modell und dessen Einbettung 
in die organisatorische und IT-Umgebung des Unternehmens bis hin zur gemeinsamen 
Bearbeitung von Prozessinstanzen in den dadurch entstehenden soziotechnischen Syste- 
men. Eine entsprechend mitwachsende Abbildung zeigt am Ende unser umfassendes Ver- 
ständnis des Geschäftsprozessmanagements. 


1.2 Blick auf die Welt, Strukturierung und Modellbildung 


Wie bereits erwähnt, gilt es für ein Unternehmen die interessierenden Geschäftsereig- 
nisse zu identifizieren und die dadurch ausgelösten Tätigkeiten zu definieren. Dazu 
ist der entsprechende Ausschnitt der Wirklichkeit zu identifizieren und genauer zu 
betrachten. 

Der Ausschnitt wird bestimmt durch die Kunden, die eine Leistung fordern, und bildet für 
die an der Leistungserbringung beteiligte Gruppe von Mitarbeitern! des Unternehmens die 
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sie unmittelbar betreffende und umgebende Wirklichkeit. Zum Erbringen der gewünschten 
Leistung müssen die Beteiligten direkt oder indirekt zusammenwirken. 

Jeder leistet dabei in Abstimmung mit den anderen seinen Beitrag. Basierend auf 
seinem persönlichen Hintergrund bezüglich Ausbildung, Wissen, Wollen (Motivation), 
Erfahrungen und Vorlieben hat jedes Gruppenmitglied eine eigene Wahrnehmung des 
Prozesses und seines Kontextes. Es entwickelt seine individuelle Vorstellung, was sein 
Beitrag sein soll, wie er erbracht wird, welche Ereignisse mit welchen Tätigkeiten und 
vom wem zu berücksichtigen sind, in welcher Reihenfolge Teilschritte stattfinden, von 
wem welche Vorleistungen erwartet und für wen welche Vorleistungen erbracht werden. 

Folglich besitzen alle Betroffenen ihr eigenes mentales „Weltmodell“ des betrachteten 
Wirklichkeitsausschnitts (vgl. Abb. 1.1). Für die erfolgreiche Reaktion auf Geschäfts- 
ereignisse gilt es, die unterschiedlichen Wirklichkeiten der Beteiligten zu strukturieren 
und in ein konsistentes Prozessmodell für ein gemeinsames zielgerichtetes Tun zu über- 
führen. Dies bedeutet, der Geschäftsprozess wird „verabredet“, in dem die einzelnen, 
mehr oder weniger gut zusammenpassenden mentalen Modelle der involvierten Personen 
harmonisiert werden. 

Dieses Zusammenführen der individuellen Vorstellungen der von einem Geschäfts- 
prozess Betroffenen und die wechselseitige Abstimmung der verschiedenen Aspekte 
eines Geschäftsprozesses (vgl. Abschn. 1.3) ist selbst ein komplexer Prozess und zentra- 
ler Aspekt des Geschäftsprozessmanagements. 


Wissen und 
Wollen - ~, 


a a 9% 


Wissen und Gemeinsames zielgerichtetes Tun, 


Wollen von Werkzeugen unterstützt = 


* 
Strukturierung, Modellbildung 


Prozessmodell 


Wissen und 
Wollen 


Abb. 1.1 Individuelle mentale Modelle der Beteiligten 
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1.3 Bestandteile einer Prozessbeschreibung 


Wir teilen eine Geschäftsprozessbeschreibung gedanklich in drei Abschnitte (vgl. 
Abb. 1.2). Der erste als Prozessstrategie bezeichnete Teil macht Aussagen zu Zweck, 
Auslöser, Inputs, Ende und Outputs des Vorgangs. Auslöser ist das Ereignis, das die 
Leistungserbringung auf Basis der Erwartungen des Initiators in Gang setzt, also eine 
Prozessinstanz erzeugt. Mit diesem Anstoß geht einher, dass der Initiator Informationen 
oder Gegenstände bereitstellt, welche entsprechend seiner Erwartungen bearbeitet wer- 
den sollen. Diese Inputs gilt es in die erwarteten Ergebnisse zu transformieren und diese 
dem definierten Empfänger zur Verfügung zu stellen. Damit schafft der Geschäftsprozess 
einen Wert, für den ein Kunde bezahlt. 

Diese Außensicht eines Geschäftsprozesses wird ergänzt durch die Prozess- 
logik. Diese innere Perspektive beschreibt die involvierten Handelnden und deren 
abgestimmtes Zusammenwirken. Die Akteure führen Aktivitäten in einer sachlogisch 
und zeitlich sinnvollen Reihenfolge aus. Die Ergebnisse ihrer Aktionen übergeben sie zur 
Weiterbearbeitung an andere Handelnde bzw. am Ende an den vorgesehenen Empfänger. 

Bei der Prozessrealisierung geht es um die Bereitstellung der Ressourcen für die 
Abarbeitung von Prozessinstanzen. Dies können Menschen, Maschinen und Software- 
systeme sein, welche als konkrete Realisierungen der involvierten Handelnden die diesen 
zugeordneten Aktivitäten übernehmen. Im Zeitalter der Digitalisierung synchronisieren 
Softwaresysteme (Process oder Workflow Engines) die Aktionen der Handelnden durch 
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Abb. 1.2 Bestandteile einer Prozessbeschreibung 
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Steuerung der zeitlichen und sachlogisch notwendigen Reihenfolge der Teilschritte 
gemäß dem Prozessmodell. Für die Erledigung ihrer einzelnen Aufgaben setzen die Han- 
delnden gegebenenfalls Hilfsmittel ein, wie Informationen, Anwendungsprogramme 
oder Werkzeuge. 

Im Rahmen der Prozessrealisierung ist dafür zu sorgen, dass auf Basis des als Mus- 
ter definierten Modells durch entsprechende Ressourcenzuordnung mehrere Prozess- 
instanzen parallel und unabhängig voneinander ausgeführt werden können. 


1.4 Rahmenbedingungen für Prozessmodelle und 
Prozessinstanzen 


Das Geschäftsmodell beschreibt im Wesentlichen, wie ein Unternehmen in die Welt 
hineinwirkt und auf welche Art und Weise es dabei Erlöse erzielt und Gewinn erwirt- 
schaftet. Von besonderer Bedeutung dabei sind das Kundenversprechen sowie die Res- 
sourcen und Partner, mit denen dieses Versprechen eingelöst wird. 

Die Unternehmensarchitektur beschreibt eine Maschinerie, mit der das Geschäfts- 
modell zum Leben erweckt werden soll. Als typisches Schichtenkonzept definiert sie 
fachliche und IT-Strukturen und verknüpft diese miteinander. Das Konzept des Business 
Engineering [1] sieht etwa auf einer strategischen Ebene die Geschäftsarchitektur mit 
der Definition von Zielen und Leistungen vor, die mit dem Geschäftsmodell verwoben 
ist. Auf der Ebene der Prozesse als Implementierungshilfsmittel der Strategie folgt die 
Prozessarchitektur mit Aufbau- und Ablauforganisation. Der Übergang zu den IT-Struk- 
turen für die Unterstützung der Prozesse führt in die Ebene der Informationssysteme mit 
der Applikationsarchitektur und der IT-Architektur. 

Die Geschäftsprozesse befinden sich also als zentraler Bestandteil der Unternehmens- 
architektur in einer Art Sandwich-Position, welche ihre Beeinflussung durch andere 
Architekturelemente verdeutlicht. Beispielsweise kann eine gegebene und nur schwer 
änderbare Organisationsstruktur die Vorgehensweisen in Prozessen und die Art, wie 
mit externen Partnern zusammengearbeitet wird, mitbestimmen. Analog gilt dies für 
die Verfügbarkeit von Ressourcen. Aber auch horizontale Abhängigkeiten innerhalb der 
Ablauforganisation sind zu berücksichtigen, etwa wenn eine bestimmte Arbeitsweise im 
Bestellprozess Auswirkungen auf die Gestaltung der Zahlungsabwicklung hat. 

Von „unten“ wirken Einflüsse nicht nur hinsichtlich der inhaltlichen Gestaltung der 
Prozessmodelle, sondern auch hinsichtlich Detailgrad und Genauigkeit. Für die Ent- 
wicklung von IT-Lösungen zur Prozessdigitalisierung gelten rigide Anforderungen an die 
Modelldefinition. Prozessteile, die mit IT-Unterstützung ausgeführt werden sollen, müs- 
sen genau und präzise spezifiziert sein. 

Neben den exemplarisch erläuterten und in Abb. 1.3 ergänzten internen Rahmen- 
bedingungen wirken auch noch externe Faktoren auf die Prozessgestaltung ein. Hier 
kann man als Beispiel Prüfschritte sehen, welche aufgrund von Compliance-Vorschriften 
in einen Ablauf aufgenommen werden müssen. 
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Abb. 1.3 Ergänzung um Rahmenbedingungen für die Prozessdefinition 


1.5 Prozesskennzahlen 


Die zu entwickelnden oder zu ändernden Prozesse haben das allgemeine Ziel, die 
Umsetzung des Geschäftsmodells und der zugehörigen Strategie zu unterstützen. Die 
Beziehung zwischen den Kennzahlen aus dem Geschäftsmodell (Key Performance Indi- 
cators, KPIs) und den Prozessen wird über Prozesskennzahlen (Process Performance 
Indicators, PPIs) hergestellt. Diese Prozesskennzahlen sind Verfeinerungen von Zielen 
aus dem Geschäftsmodell (vgl. Abb. 1.4). 

Typische betriebswirtschaftliche Key Performance Indicators leiten sich aus 
Geschäftsmodell und -strategie ab und messen den Geschäftserfolg auf höheren 
Aggregationsebenen, z.B. Erlöse und Kosten auf Gesamtunternehmens-, Sparten-, 
Produktgruppenebene etc. Hier steht die Effektivitätsbetrachtung im Vordergrund 
(„Doing the right things“). Mit den Geschäftsprozessen werden die Strategie umgesetzt 
und die Elemente der Unternehmensarchitektur zusammengeführt. Die damit ver- 
bundenen Process Performance Indicators zielen auf die Effizienz ab („Doing things 
right“). Sie stehen damit in engem Zusammenhang mit den Key Performance Indicators 
und leiten sich teilweise von diesen ab. 

Beim Ableiten der Kennzahlen muss bereits geprüft werden, ob diese mit vertret- 
barem Aufwand in ausreichender Präzision gemessen werden können. Unter Umständen 
ergeben sich daraus auch Anforderungen an den zu entwickelnden Prozess, um die 
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Abb. 1.4 Definition von Prozesskennzahlen 


Kennzahlen direkt oder indirekt messen zu können. Ist unmittelbare Messung nicht mög- 
lich, können auch Ziele für Ersatzkennzahlen festgelegt und daraus Werte für den eigent- 
lich gewünschten Performance Indicator abgeleitet werden. 

Für die Prozesskennzahlen werden Zielwerte festgelegt, die es durch einen geänderten 
oder neu zu gestaltenden Prozess zu erreichen gilt. Während des ganzen Wegs von der 
Identifikation des Problems, bis hin zur Inbetriebnahme eines geänderten oder neuen 
Prozesses gilt es laufend zu plausibilisieren, ob mit dem entstehenden Prozess die 
angestrebten Ziele erreicht werden können. 


1.6 Unterstützungskonzepte 


Der Weg vom individuellen Wissen und Wollen, also von den mentalen Modellen der 
Beteiligten zu einem Prozessmodell, das auch zumindest in Teilen digitalisiert werden 
kann, ist komplex und aufwendig. Um Komplexität und Aufwand zu reduzieren, wur- 
den Unterstützungskonzepte wie Frameworks, Vorgehensmodelle und Beschreibungs- 
sprachen entwickelt. 

Die folgende Übersicht umfasst eine thematisch gruppierte Auswahl solcher Hilfs- 
mittel, welche nach unseren Erfahrungen in der Praxis weit verbreitet sind. Sie 
sind in Abb. 1.5 eingefügt und werden in den Kapiteln zu Modellen (Kap. 2) und 
Modellierungssprachen (Kap. 3) genauer betrachtet. 
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Abb. 1.5 Ergänzung um Konzepte zur Unterstützung der Prozessdefinition 


Frameworks für das Qualitätsmanagement: 


e Total Quality Management (TQM) TQM/PDCA, 

e Deming-Zyklus (PDCA, Plan-Do-Check-Act) 

e EN ISO 9001 

e European Foundation for Quality Management (EFQM) 


Frameworks für das Unternehmensarchitekturmanagement (Enterprise Architecture 
Management, EAM): 


e Zachman-Framework 
e The Open Group Architecture Framework (TOGAF) 
e Architecture-Animate (ArchiMate) 


Frameworks für IT-Management und IT-Governance: 


e IT Infrastructure Library (ITIL®) 
e Control Objectives for Information and Related Technology (COBIT) 


10 1 Motivation 


Beschreibungssprachen für die Prozesslogik: 


e Flussdiagramme 

e Ereignisgesteuerte Prozessketten mit Erweiterung (EPK, eEPK) 
Business Process Model and Notation (BPMN) 
Subject-oriented Business Process Management (S-BPM) 


1.7 Digitalisierung 


Heute ist Digitalisierung das Schlüsselwort bei der Transformation der Wertschöpfung. 
Digitalisierung in der Wirtschaft oder allgemein in Organisationen heißt Digitalisie- 
rung von Geschäftsmodellen, Produkten und Services sowie von ganzen Prozessen 
oder Teilen davon. Bei Prozessen bedeutet dies jedoch nicht notwendigerweise Voll- 
automatisierung ohne jeglichen menschlichen Eingriff. So kann es beispielsweise sein, 
dass ein Programm, das einen Prozess steuert, bei entsprechender Notwendigkeit Aktio- 
nen einbindet, die von Menschen oder auch Cyber Physical Systems ausgeführt wer- 
den. Letztere bestehen aus miteinander kommunizierenden Geräten mit Software sowie 
mechanischen und elektronischen Komponenten. 

In der Initiative Industrie 4.0 wird diese umfassende Betrachtung von Prozessen, d. h. 
die Kommunikation zwischen Menschen, Maschinen und Werkstücken angestrebt. Diese 
Aspekte müssen zum einen in den Prozessmodellen ausgedrückt werden können und 
zum anderen muss die Überführung eines Geschäftsprozessmodells in die digitale Aus- 
führung so weit wie möglich unterstützt werden. Insbesondere wenn man die Aspekte des 
Qualitätsmanagements, also die laufende Verbesserung der Prozesse, in die Betrachtung 
einbezieht, müssen Prozessänderungen, die eine Änderung der Digitalisierung nach sich 
ziehen, schnell und mit möglichst geringem Aufwand umgesetzt werden können. 

Die in den vorangegangenen Abschnitten beschriebenen Aspekte müssen bei der 
Modellbildung bereits mit einfließen, um die technische Implementierung von Prozessen 
zu erleichtern, ohne jedoch Implementierungsdetails vorweg zu nehmen (vgl. Abb. 1.6). 
Je präziser die Prozesse beschrieben sind, umso leichter fällt dies. Prozessabschnitte, 
deren Ablauflogik zum Zeitpunkt der Modellierung noch nicht präzise beschrieben 
werden können, sind entsprechend zu kennzeichnen. Diese Teile eines Prozesses kön- 
nen aber mit anderen geeigneten Methoden gemäß der gewünschten oder notwendigen 
Offenheit modelliert werden. Solche Prozessabschnitte können entweder mit Adaptive 
Case Management Methoden beschrieben werden oder, falls eine kommunikations- 
orientierte Beschreibungssprache verwendet wird, als Kommunikationsschleife. Letztere 
beendet einer der beteiligten Partner nach Erreichen eines entsprechenden Ergebnisses, 
ehe im Prozess fortgefahren wird. 

Wichtig in diesem Kontext ist die Granularität, also der Detailgrad der Prozess- 
beschreibung. Aktivitäten sollten so fein geschnitten werden, dass man eindeutig fest- 
legen kann, ob sie digitalisiert, teildigitalisiert (Mensch-IT, Physik-IT) oder manuell von 
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Abb. 1.6 Berücksichtigung von Digitalisierungsaspekten im Modell 


Menschen ausgeführt werden. Der Zuschnitt sollte sich an den fachlichen Anforderungen 
orientieren und nicht an der Funktionalität eines möglicherweise schon vorhandenen 
IT-Systems. Notfalls muss ein derartiges System bei der Prozessumsetzung an dessen 
fachliche gewünschte Spezifikation angepasst werden. 


1.8 Prozess zum Erstellen von Prozessen 


Die Definition der Geschäftsprozesse kann nicht schematisch bzw. algorithmisch 
erfolgen, d.h., es gibt keine Software, die gefüttert mit dem Geschäftsmodell, der 
Unternehmensarchitektur, den Kennzahlen mit dazugehörigen Zielwerten und Unter- 
stützungskonzepten, nach kurzer Zeit eine passende Prozessbeschreibung ausgibt. 

Die Definition von Geschäftsprozessen ist ein intuitiver und kreativer Prozess. Des- 
halb werden v.a. zu Beginn von Geschäftsprozessmanagementaktivitäten auch Kreativi- 
tätstechniken und Methoden des Wissensmanagements wie Storytelling, World Cafe oder 
Value Networks eingesetzt. 

So kann man sich beispielsweise des Design-Thinking-Ansatzes bedienen. Dabei han- 
delt es sich um ein Konzept, bei dem interdisziplinäre Teams in einem die Kreativität 
fördernden Umfeld in einem iterativen Prozess zusammenarbeiten, um innovative Lösun- 
gen für eine Problemstellung zu entwickeln (vgl. Abschn. 4.3). Ein Kernpunkt ist dabei 
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ein tiefes Verständnis für die Bedürfnisse und Motivationen von Menschen der Ziel- 
gruppe zu entwickeln und zu berücksichtigen. Design Thinking bietet eine umfangreiche 
Methodensammlung für die Nutzung in den einzelnen Schritten seines Vorgehens. Mit 
diesen Eigenschaften lässt sich der Ansatz auch für die Überarbeitung bzw. Neudefinition 
eines Geschäftsprozesses einsetzen. Unter Umständen lassen sich dabei außergewöhnli- 
che Lösungen finden, die beim üblichen BPM-Vorgehen nicht entstanden wären. 

Allerdings muss ein kreatives, innovatives Prozesskonzept auch detailliert aus- 
gearbeitet und umgesetzt werden. Die kreative Gestaltung ist deshalb eingebettet in 
Bündel von Aktivitäten, die den Prozess letztlich Teil der realen Welt werden lassen. 
Als solche Aktivitätsbündel identifizieren wir Analyse und Modellierung, Validierung, 
Optimierung, organisatorische Implementierung, IT-Implementierung sowie Betrieb und 
Monitoring. Diese Aktivitätsbündel sind eine Weiterentwicklung bzw. Verfeinerung des 
Plan-Do-Check-Act-Kreislaufs. Sie werden meist kreisförmig angeordnet, was einen 
entsprechenden Durchlauf impliziert. Dies entspricht nicht immer dem Vorgehen in der 
Realität, weshalb wir die Aktivitätsbündel in Abb. 1.7 als lose vernetzte Waben dar- 
stellen. Dort sind die Phasen des Design-Thinking-Prozesses und die Aktivitätsbündel 
ergänzt. Beide Konzepte werden in Kap. 4 ausführlicher vorgestellt und miteinander in 
Beziehung gesetzt. 

Umfangreiche und komplexe Prozessänderungen bedürfen meist Tätigkeiten aus meh- 
reren Aktivitätsbündeln und werden als Projekt durchgeführt. Ein solches Projekt kann 
deshalb als ein Durchlauf (Prozessinstanz) des Prozesses zum Erstellen von Geschäfts- 
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Abb. 1.7 Ergänzung um die Vorgehensstruktur und Planung für Prozessänderungen 
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prozessen betrachtet werden. Dafür ist eine detaillierte Projektplanung zu erstellen 
mit den auszuführenden Tätigkeiten, Zuständigkeiten und Terminen (vgl. Abb. 1.7). 
Der Projektplan sollte dann entsprechend den Methoden des Projektmanagements 
abgearbeitet werden. 


1.9 Organisatorische und technische Implementierung 


Nach der Erstellung des Prozessmodells gilt es, das Modell in die Organisationsstruktur 
eines Unternehmens einzubetten. Es wird damit festgelegt, welche Tätigkeit von wel- 
cher Person oder Organisationseinheit ausgeführt wird. Diese Zuordnung muss nicht 
statisch sein, sondern kann von Instanz zu Instanz variieren. So kann beispielsweise der 
Einkaufsprozess für die Teile A und B die gleiche Ablauflogik haben, allerdings ist für 
den Einkauf der Teile A eine andere Einkaufsabteilung zuständig als für die Teile B. 
Prozessinstanzen für die Teile A tangieren also andere Organisationseinheiten (und ihnen 
zugeordnete Personen) als für Teile B. Diese Regeln sind so abzubilden, dass ein Prozess 
richtig mit der Aufbauorganisation verknüpft wird. 

Neben Tätigkeiten, die durch Menschen ausgeübt werden, können im Prozess auch 
Aktivitäten vorkommen, welche Anwendungsprogramme oder IT-Services ausführen. 
Dazu sind solche Aktionen im Prozessmodell auf Funktionen von Softwarebausteinen 
abzubilden, welche diese dann zur Laufzeit ausführen. Wurde bei der Prozess- 
modellierung schon auf die mögliche Digitalisierung geachtet, so ist diese Abbildung 
mehr oder weniger unproblematisch. 

Software kann auch die Abarbeitung von Vorgangsschritten steuern und dabei die im 
Modell spezifizierten Aufgaben den jeweils vorgesehenen Personen oder IT-Services 
als Akteur zuordnen. Softwaresysteme, die dies unterstützen, werden auch als Work- 
flow-Systeme (Process Engine, Workflow Engine) bezeichnet. Im Idealfall können 
Prozessbeschreibungen direkt in Workflow-Systeme übernommen werden. 

Nach der Einbettung in die Organisation und in die IT-Umgebung kann ein Pro- 
zess für die Abwicklung von Instanzen, also echten Geschäftsfällen verwendet werden, 
das Ziel ist erreicht. Abb. 1.8 zeigt den nun vervollständigten Weg von den individuel- 
len mentalen Modellen mit dem Wissen und Wollen der Beteiligten zur gemeinsamen 
Bearbeitung von Prozessinstanzen. 


1.10  Erfolgsmessung mit Kennzahlen 


Bei der Ausführung von Instanzen eines Prozesses kann überprüft werden, ob die 
für die Prozesskennzahlen definierten Zielwerte erreicht werden. Dazu werden Ist- 
werte für die festgelegten Key und Process Performance Indicators (KPIs und PPIs) 
gemessen, berechnet, gespeichert und mit den Zielwerten verglichen (vgl. Abb. 1.9). 
Dieser Vergleich kann in Realzeit oder über längere Zeitintervalle erfolgen. Eine 
Realzeitauswertung führt bei einer Zielabweichung zur sofortigen Einleitung geeigneter 
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Abb. 1.8 Ergänzung um die Einbettung in die Organisation und IT-Umgebung 
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Abb. 1.9 Betrieb, Monitoring und Kennzahlen 
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Gegenmaßnahmen. Eine Auswertung von Messwerten über längere Zeit zeigt dagegen 
mittel- bis langfristige Trends von Kennzahlen und kann entsprechende Änderungen aus- 
lösen. Auswertungsergebnisse werden u. a. in Prozesscockpits visualisiert. 


1.11 Kontinuierliche Verbesserung 


Prozesse sind nicht statisch, sondern unterliegen Veränderungen der in Abschn. 1.4 
erläuterten internen und externen Rahmenbedingungen. Entwicklungen wie Geschäfts- 
modellmodifikationen, neue Wettbewerber, technischer Fortschritt oder Ver- 
schlechterungen bei gemessenen Prozesskennzahlen wie der Durchlaufzeit können 
Anpassungen eines Prozesses erfordern. Dazu sind passende Maßnahmen im Rahmen 
der in Abschn. 1.8 vorgestellten Aktivitätsbündel und Vorgehensweisen zu ergreifen. 

Der Feedback-Pfeil in Abb. 1.10 deutet an, dass dazu die Beteiligten möglicherweise 
erneut divergierende Sichten des Realitätsausschnitts haben. Mit deren Harmonisierung 
in der beschriebenen Weise wird eine neue Instanz des Prozesses zur Erstellung von Pro- 
zessen gestartet. 

Die kontinuierliche Verbesserung ist ein sehr wesentlicher Aspekt des Prozess- 
managements. Durch laufende Anpassungen nähert man sich dem gewünschten Prozess 
immer mehr an. Allerdings können Veränderungen im Umfeld diese Annäherung beein- 
flussen. Der angestrebte Zustand ist also ein bewegliches Ziel (‚moving target‘). 


IV) Geschäftsmodell und -strategie 
Yy Unternehmensarchitektur Bestandteile einer Prozessbeschreibung 


yy Geschäftsprozesse m Prozessstrategie: Ein Prozess hat 
m einen definierten Anfang (Startereignis) und Input, 
Unterstützungskonzepte: m weißt ein definiertes Ende und Ergebnis auf, 
Total Quality Management, Plan-Do-Check-Act, ISO m das zur Befriedigung eines Kundenbedürfnisses 
9001, EFQM, ITIL, TOGAF, ArchiMate (und damit zur Wertschöpfung) beiträgt 


Prozesslogik: Ein Prozess ist 

= die Summe von miteinander verknüpften Aktivitäten 
(Aufgaben), 

= die nach dem Startereignis von Handelnden 

m in sachlogischer und zeitlicher Reihenfolge 

m zur Bearbeitung eines Geschäftsobjekts ausgeführt 
werden um 

m das gewünschte Ergebnis zu erzeugen. 

Prozessrealisierung: Ein Prozess wird realisiert 

Design m mit Menschen und/oder Maschinen, die Aufgaben 

Thinking der jeweiligen Handelnden übernehmen, und diese 

= mit Hilfsmitteln (Sachmittel, Information, 
‚Anwendungsprogramme etc.) ausführen. 


Beschreibungssprachen: 
Sprachgrammatik, Flussdiagramme, EPK, eEPK, 
BPMN, S-BPM, ... 


Digitalisierung 
umsetzungsgetreue Spezifikation, Datenhhaltung, 
Datenverarbeitung, Ablauf- und 
Kommunikationssteuerung, IT-Plattform 


Mentale 
Welt- 
modelle 


sJoresipuj ƏJUewWOJƏd SSƏJ01d Z AƏJ 


Vorgehensstruktur 
Verbesserung? 


Gemeinsames zielgerichtetes Tun, 
von Werkzeugen unterstützt 


u KPIs i 
r & PPIs m] 
ee] 
TE e) E 


Organisatorische und Betrieb & 
Prozessmodell techn. Implementierung Monitoring 


Aktivitäts- 
bündel 


Abb. 1.10 Ergänzung um kontinuierliche Verbesserung 
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1.12 _ Unternehmensführung und 
Geschäftsprozessmanagement 


Die Unternehmensführung als Institution gestaltet das Unternehmen. Sie bestimmt 
maßgeblich das Geschäftsmodell, die Unternehmensstrategie und die Organisation. 
Geschäftsmodell und Strategie sollen zukünftige Erfolgspotenziale erschließen und 
damit die nachhaltige Existenz des Unternehmens sichern. Mit der Unternehmensarchi- 
tektur wird die Infrastruktur zur Ausschöpfung der Erfolgspotenziale geschaffen. Die 
Geschäftsprozesse und die in ihnen bearbeiteten Geschäftsobjekte (Daten) verknüpfen 
die fachliche mit der technischen Ebene der Unternehmensarchitektur. 

Die Geschäftsprozesse sind Gegenstand der Digitalisierung, d. h. der informations- 
technischen Unterstützung der Prozessausführung durch Menschen und Maschinen. In 
den letzten Jahren haben sich die diesbezüglichen Anforderungen deutlich vergrößert. 
So sollen in Geschäftsprozessen nicht nur Menschen und IT-Systeme, sondern auch 
„smarte“ Maschinen und Geräte interagieren können. Gemeint sind hochintegrierte 
Geschäftsprozesse im Kontext von Industrie 4.0 und Internet of Things, die sowohl 
menschliche Akteure, als auch einzelne Geräte und Maschinen zu einem gemeinsamen 
Ganzen integrieren. Die technischen Akteure werden dabei oftmals als „smart‘“ oder 
„intelligent“ bezeichnet. 

Unternehmensführung als Prozess bezeichnet die Managementtätigkeiten bei der 
Schaffung und Ausschöpfung der Erfolgspotenziale. Im Kontext des Geschäftsprozess- 
managements bedeutet sie das Management von soziotechnischen Systemen mit Men- 
schen, die in Prozesse eingebunden sind, und mit Maschinen, die Menschen bei ihren 
Tätigkeiten unterstützen oder Folgen von Tätigkeiten autonom ausführen. 

Trotz der zunehmenden Bedeutung der Digitalisierung steht der Mensch als 
Gestalter von soziotechnischen Systemen und Anwender der unterstützenden Technik 
im Mittelpunkt des Prozessmanagements. Nicht zuletzt aufgrund steigender Agilitäts- 
anforderungen ist es heute Ziel, dass die Mitarbeiter, so weit wie möglich, autonom 
und selbstständig die operativen Prozesse gestalten (modellieren) können und diese 
danach ohne wesentliche Verzögerungen und zusätzlichen Aufwand direkt informations- 
technisch unterstützt werden. Mit einem deutlichen Bekenntnis zur Prozessorientierung 
muss die Unternehmensleitung muss die Voraussetzungen dafür schaffen („Tone from 
the top“). Diese umfassen sowohl die notwendige Infrastruktur als auch ein Umfeld, das 
Menschen ermutigt, sich aktiv in die Prozessmanagementaktivitäten einzubringen. 

Der Grad der Einbindung der Mitarbeiter ist geprägt vom Menschenbild und der damit 
verbundenen Führungsphilosophie der Unternehmensleitung (,Tone at the top“). Bei 
einem klassischen, eher hierarchisch geprägten Ansatz werden die Menschen und ihre 
Fähigkeiten als Ressource betrachtet, die Gegenstand der Handlungen von Führungs- 
kräften sind und schließlich Anweisungen ausführen. Eine derartige Managementphilo- 
sophie ist gekennzeichnet durch direkte Intervention der Unternehmensführung und 
folgt der Theorie X. Gemäß dieser Theorie wird etwaiger fehlender Motivation durch 
Androhung von Sanktionierung seitens der Unternehmensführung begegnet. 
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Im mehr systemischen, d.h. ganzheitlichen Ansatz wie er dem St. Gallener 
Managementmodell zugrunde liegt, soll ein System geschaffen werden, das selbst und 
weitgehend selbstständig an der Gestaltung eines Geschäftsprozessmanagementsystems 
arbeitet. Alle Mitarbeiter sollen sich aktiv einbringen können. Dieser Managementstil 
folgt dem Menschenbild gemäß Theorie Y. Danach sind die wesentlichen Merkmale 
eines Menschen Freude an anspruchsvoller Arbeit, Selbstdisziplin, Verantwortung und 
Verstandeskraft. 

Ergänzt wird dieses Menschenbild durch entsprechende Organisationstheorien. Diese 
haben den Zweck, das Entstehen, Bestehen und die Funktionsweise von Organisationen 
zu erklären. Organisationstheorien setzen implizit ein bestimmtes Menschenbild voraus. 
So geht der Taylorismus überwiegend von einem Menschenbild aus, das der Theorie X 
entspricht. Die systemische Organisationstheorie nach Luhmann macht hingegen keiner- 
lei ethische Annahmen zu den Menschen in einer Organisation, sie nimmt nur an, dass 
diese miteinander kommunizieren. Der Schwerpunkt bei der Theorie des Kommunikati- 
ven Handelns liegt zwar auch auf der Kommunikation, aber durch Theorie und Vernunft 
soll die Welt verändert werden. Es wird davon ausgegangen, dass der Mensch von Natur 
aus einsichtig und offen für Argumente ist. 

Zu den verschiedenen Menschenbildern gibt es passende Managementphilosophien 
und Organisationstheorien. Art und Einsatz von Methoden, Techniken und Werkzeuge 
müssen damit in Einklang stehen. Beispielsweise passt es nicht zusammen, die Ein- 
bindung von Mitarbeitern zu propagieren, wenn die Unternehmensführung dann deren 
Vorschläge nicht ernst nimmt oder gar nicht wahrnimmt. Bevor es an die Gestaltung 
von Prozessen geht, sollte sich ein Unternehmen deshalb bewusst machen, welches 
Menschenbild seine Führungs- und Unternehmenskultur prägt. 

Wir denken, dass es insbesondere für die mit der Digitalisierung verbundenen Heraus- 
forderungen einer Ausrichtung zu Theorie Y bedarf, welche in der Praxis häufig zu 
Kulturwandel führen wird (müssen). 
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Modelle 


Im vorangegangenen Kapitel haben wir die vielfältigen Aspekte des Geschäftsprozess- 
managements umrissen. Da in der Praxis häufig Modelle für die Beschreibung dieser 
Aspekte zum Einsatz kommen, gehen wir in den folgenden Abschnitten zunächst näher 
auf die Aufgaben und Eigenschaften von Modellen und Modellbildung ein. Danach 
stellen wir Beispiele von Modellen aus verschiedenen Fachgebieten vor, welche sich 
nach unserer Erfahrung in zahlreichen Geschäftsprozessmanagementprojekten als hilf- 
reich erwiesen haben. Die Darstellung erhebt keinen Anspruch auf Vollständigkeit, kann 
jedoch dem Leser als Orientierung dienen, wenn er selbst Beschreibungsmodelle für sein 
individuelles Projekt auswählen muss. 


2.1 Modell und Wirklichkeit 


„Man muss die Welt nicht verstehen, man muss sich nur darin zurecht finden“. Im Inter- 
net wird dieser Satz Albert Einstein zugeschrieben. Wer versteht schon, was in der 
Welt alles geschieht? Wer weiß schon, wie sie funktioniert? Daher sollten wir uns um 
unsere Welt kümmern, um den Teil der Welt, der uns momentan wichtig ist. Wir sollten 
erkennen, dass wir uns unsere Welt täglich erschaffen bzw. konstruieren. Ein betrachteter 
Ausschnitt ist natürlich bestimmt von unseren subjektiven Interessen. 

Wir entscheiden, welchen Ausschnitt der Welt wir betrachten wollen, und welche 
Aspekte uns darin wichtig erscheinen. Wir identifizieren dabei die für uns wesentlichen 
Artefakte und die für uns wesentlichen Beziehungen zwischen ihnen. Eine solche Abs- 
traktion eines Ausschnitts der Wirklichkeit wird als Modell bezeichnet. Es kann auch 
sein, dass der betrachtete Ausschnitt der Wirklichkeit bereits ein Modell ist. Damit kön- 
nen Teile eines bereits existierenden Modells näher betrachtet werden. Dies wäre dann 
ein Modell eines Modells. Dieses Hochschrauben kann beliebig fortgesetzt werden. 
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Abb. 2.1 Modellbildung 


Jede Person hat eine eigene, subjektive Sicht auf die Welt oder einen Ausschnitt der 
Welt. Verschiedene Menschen betrachten den gleichen Ausschnitt der Wirklichkeit, kom- 
men allerdings zu unterschiedlichen Modellen, da sie unterschiedliche Schwerpunkte 
setzen (vgl. Abb. 2.1). 

Da Modelle nicht alle Aspekte der zugeordneten Wirklichkeit abdecken, gibt es 
durchaus Vorfälle in der Wirklichkeit, die durch ein Modell nicht abgedeckt sind und in 
ihm nicht nachvollziehbar sind. Diese nicht in einem Modell erklärbaren Phänomene bil- 
den dessen Grenzen. Der Erschaffer eines Modells kann nun entscheiden, dass er dieses 
anpasst, weil er die bisher nicht abgedeckten Phänomene auch mit einbeziehen möchte, 
oder er legt fest, dass er diese nicht weiter betrachten möchte. Jedes Modell ist und bleibt 
eine Vereinfachung der Wirklichkeit, weshalb es immer Phänomene geben wird, die von 
einem Modell nicht erfasst werden. 

Jeder Anwender muss entscheiden, ob das von ihm verwendete Modell für seine 
Versuche, sich in der Welt zurecht zu finden, ausreicht. Möchte man mit einem Modell 
alle Aspekte der Wirklichkeit abdecken, erreicht es die Komplexität der Wirklichkeit. 
Dann versteht man das Modell nicht mehr, so, wie man vorher die Wirklichkeit nicht 
verstanden hat. Der Sinn eines Modells, nämlich die Wirklichkeit besser begreifbar und 
handhabbar zu machen, wird nicht mehr erreicht. 

Das Kreieren eines Modells und seine Verwendung sind subjektive Tätigkeiten, 
d. h. der Ersteller wählt die Eigenschaften der Wirklichkeitsabbildung nach seinen Vor- 
stellungen aus. Allerdings ist es üblich, dass sich Gruppen von handelnden Personen, in 
weiterer Folge als Subjekte oder Akteure bezeichnet, auf ein Modell zur Betrachtung der 
Wirklichkeit einigen. Viele wissenschaftliche Schulen basieren auf solchen gemeinsamen 
Modellen der involvierten Forscher. 
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Modellbildung ist eine wesentliche Tätigkeit in allen Wissenschaften, seien es Philo- 
sophie, Soziologie, Physik, Chemie, alle Ingenieurswissenschaften, Ökonomie usw. 
Die jeweiligen Modelle haben dabei verschiedene Aufgaben: Entweder bilden sie den 
betrachteten Ausschnitt ab, wie in den Naturwissenschaften üblich, oder sie dienen 
dazu, bestimmte notwendige Änderungen an dem betrachteten Ausschnitt der Wirk- 
lichkeit auszuprobieren (Simulationsmodell). Dies ist beispielsweise wichtig, um keine 
Menschenleben zu gefährden. Die Sicherheitsmodelle von Autos werden vor deren 
Serienproduktion in entsprechenden Tests auf ihre Eigenschaften hin überprüft. Dies 
geschieht nicht mit Menschen, sondern Modellen von Menschen, sogenannten Dum- 
mies. Dabei werden zwei Modelle miteinander kombiniert: Das Automodell, das die ent- 
sprechenden Sicherheitskonzepte umsetzt, und das Menschenmodell (Dummy), um die 
Verletzungsrisiken zu untersuchen. 

Der in einem Modell erfasste Sachverhalt kann nun so lange angepasst werden, bis 
bei den mit dem Modell betrachteten Phänomenen das gewünschte Ergebnis erreicht 
wird. Beispielsweise werden dem Sicherheitsmodell eines Autos weitere Sicherheits- 
konzepte hinzugefügt, bis die gewünschte Reduktion des Verletzungsrisikos erreicht 
wird. Solche Modelle sind dann keine Abbilder der Wirklichkeit mehr, sondern stellen 
eine gewünschte Wirklichkeit dar. Die gewünschten Eigenschaften werden dann in die 
Wirklichkeit zurück transferiert, indem man beispielsweise die im Modell überprüften 
Sicherheitskonzepte in die Serienautos einbaut. 

Ziel bei der Modellbildung ist immer, dass wir uns in der Welt zurechtfinden, oder 
gefahrlos ausprobieren können, wie eine entsprechende Änderung der Wirklichkeit sich 
auswirken würde. Zu verstehen, was die Welt im Innersten zusammenhält, wird uns wie 
es aussieht auf absehbare Zeit damit nicht gelingen. Das entsprechende Modell wäre 
dann die Welt, die es nicht gibt [1]. 


2.2 Eigenschaften von Modellen 


Modelle dienen sowohl der abstrakten Darstellung der betrachteten Wirklichkeit im Sinne 
einer Erkenntnisfunktion als auch der Gestaltung der betrachteten Realität im Sinne 
eines Rückschlusses. Wie bereits angesprochen wird ein Modell so verändert, dass es 
einer gewünschten Wirklichkeit entspricht und dann als Bauplan für eine entsprechende 
Umgestaltung der Realität verwendet. In Naturwissenschaften wie der Physik haben 
Modelle überwiegend eine Erkenntnisfunktion, während sie in den Ingenieurwissen- 
schaften und der Betriebswirtschaft die Gestaltung der Wirklichkeit unterstützen sollen [2]. 

Bei der Präzisierung des bisher verwendeten Modellbegriffs lehnen wir uns an 
Herbert Stachowiak an, der in seiner Modelltheorie die Merkmale und die daraus 
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abgeleiteten Eigenschaften von Modellen genauer untersucht hat [3]. Demnach sind 
Modelle durch mindestens drei Merkmale gekennzeichnet [3]: 


1. Abbildung 
Ein Modell ist stets ein Modell von etwas. Es kann die Abbildung oder Repräsen- 
tation eines natürlichen oder künstlichen Originals sein, wobei dieses Original wie- 
derum selbst ein Modell sein kann. Die Originale können auf natürlichem Wege 
entstanden, technisch produziert oder sonst wie einfach gegeben sein. Modelle kön- 
nen sehr unterschiedlich beschrieben bzw. repräsentiert werden: 
— Mentale Modelle: Vorstellung im Kopf 
— Verbale Modelle: Natürlich-sprachliche Beschreibung 
— Grafische Modelle: Technische Zeichnungen oder sonstige Bilder 
— Materielle Modelle: Modelle von Gebäuden 
— Formale Modelle: Mathematische Modelle, Computerprogramme usw. 
Ein Modell und das Original bilden eine Klasse von Attributen. Unter Attributen 
versteht man Merkmale und Eigenschaften von Individuen, Relationen zwischen 
Individuen, Eigenschaften von Eigenschaften, Eigenschaften von Relationen usw. 
Stachowiak überlässt dem modellierenden Subjekt, was ein Individuum ist. Er sieht 
Individuen als Attribute nullter Stufe. Mengen von Attributen können zu Klassen 
zusammengefasst werden und bilden dann Attribute der ersten Stufe. Diese Klassen 
können wieder zu einer nächsten Attributstufe zusammengefasst werden usw. 
2. Verkürzung 
Ein Modell erfasst im Allgemeinen nicht alle Attribute des betrachteten Originals, 
sondern nur diejenigen, die dem Modellschaffern bzw. Modellnutzern als relevant 
erscheinen. 
Nicht alle Attribute des Originals werden von einem Modell erfasst. Bereits mit die- 
sem Merkmal ist im weiteren Sinne eine pragmatische Betrachtungsdimension ein- 
geführt worden. Im „weiteren Sinne“ bedeutet hier, dass noch nicht spezifische 
pragmatisch-operationale Gesichtspunkte betrachtet werden, nach denen die Attribut- 
klassen, die in ein Modell eingehen sollen, selektiert werden. Diese erste Auswahl der 
Attribute ist intuitiv und willkürlich. Im engeren Sinn pragmatisch ist die Verkürzung 
erst dann, wenn die Absichten und operationalen Zielsetzungen des Modellerstellers 
bzw. Modellbenutzers die Auswahl der modellrelevanten Attribute beeinflussen. Diese 
Anpassungen an den beabsichtigten praktischen Gebrauch erfolgt erst im nächsten 
Schritt. 
3. Pragmatismus 
Nach der intuitiven Auswahl der Attribute wird überprüft, ob damit der beabsichtigte 
Zweck erreicht wird. Modelle sind ihren Originalen nicht eindeutig zugeordnet. Sie 
erfüllen eine Ersetzungsfunktion 
— für bestimmte erkennende bzw. handelnde modellbenutzende Subjekte (für wen?). 
Modelle sind nicht nur Modelle von etwas, sie sind auch Modelle für jemanden. 
Dieser Jemand kann ein Mensch oder auch ein künstlicher Modellbenutzer wie 
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z. B. ein Computerprogramm sein. Für einen Modellierer können Modelle dazu 
dienen, sich in der Welt zurecht zu finden, d.h. der Modellierer ist gleichzeitig 
auch Nutzer des Modells. Modellierer und Modellnutzer können aber auch zwei 
unterschiedliche Subjekte sein. 

— innerhalb bestimmter Zeitintervalle (wann?) 
Modelle erfüllen auch eine Funktion über die Zeit, d. h. ihre Nutzung ist auf einen 
bestimmten Zeitpunkt oder auf ein definiertes Zeitintervall bezogen. Innerhalb 
dieser Zeit können sich die betrachtete Wirklichkeit oder die Vorstellungen des 
Modellierers oder Modellanwenders derart verändert haben, dass zusätzliche Attri- 
bute in ein Modell einfließen sollen 

— unter Einschränkung auf bestimmte gedankliche oder tatsächliche Operationen 
(wozu?). 
Modelle werden zu einem bestimmten Zweck geschaffen, sei es, damit ein 
bestimmter Ausschnitt der Wirklichkeit besser verstanden werden kann, oder, um 
einen Bauplan für den Umbau der Wirklichkeit zu bekommen. 


Bei der Erstellung eines Modells stecken Modellierende immer in einem gewissen 
Dilemma. Zum einen soll das Modell in ausreichendem Maße die gewünschten Aspekte 
der Wirklichkeit wiedergeben, wobei nicht klar definiert ist, was ausreichend ist; Zum 
anderen soll das Modell nicht zu komplex sein, damit es noch handhabbar bleibt. Die- 
ser Zielkonflikt führt dazu, dass die meisten Modelle iterativ weiterentwickelt werden, 
bis sie wegen der steigenden Komplexität das Ende ihres Lebenszyklus erreichen, da sie 
nicht mehr handhabbar sind. 

In den folgenden Abschnitten stellen wir Beispiele für Modelle vor, die Aspekte 
betrachten, welche explizit oder implizit in Modelle für Geschäftsprozesse einflie- 
ßen. Wir haben die Beispiele gruppiert in Modelle aus den Sozialwissenschaften, der 
Betriebswirtschaftslehre, der Wirtschaftsinformatik und der Informatik. Die Einordnung 
in diese Gruppen ist teilweise nicht überschneidungsfrei, da insbesondere die Wirt- 
schaftsinformatik als Querschnittsdisziplin Sachverhalte grundsätzlich aus mehreren Per- 
spektiven betrachtet. 


2.3 Modelle der Sozialwissenschaften 


Geschäftsprozessmanagement hat mit Menschen und Maschinen zu tun. Es möchte 
deren Zusammenwirken unter Berücksichtigung von Zusatzanforderungen der tech- 
nischen sowie der ökonomischen und ökologischen Machbarkeit organisieren. 
Insbesondere das Zusammenwirken und Zusammenleben der Menschen ist schon Jahr- 
tausende lang Thema der Philosophie. Die Philosophie als die Lehre von den grund- 
legenden Bestimmungen und Strukturen des Lebens, der Welt und des Wissens versucht, 
die Welt und die menschliche Existenz zu ergründen, zu deuten und zu verstehen. Die 
ursprüngliche Bedeutung von Philosophie war die Lehre vom guten Leben. 
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In diesem Sinn ist Philosophie der Versuch, das umfassende Modell unserer Welt zu 
kreieren was bisher noch nicht gelungen ist. Gesellschaftsphilosophen reduzieren den 
Blick und versuchen ein Modell der Gesellschaft als einen Ausschnitt der Wirklich- 
keit zu schaffen und damit deren Sinn und Wesen besser zu verstehen. Insbesondere 
beleuchten Gesellschaftsphilosophien das Verhältnis zwischen dem einzelnen Menschen 
und der Gemeinschaft sowie die Strukturen des Zusammenlebens. Sie gelten deshalb 
auch als Philosophievarianten, welche die Soziologie berühren. Sie sollen Soziologen 
dabei helfen, gesellschaftliche Vorgänge zu analysieren und Organisationsentwickler 
bei ihrer Arbeit unterstützen, und den „normalen“ Menschen helfen, sich in der Welt 
zurecht zu finden. Es gibt zahlreiche Organisationstheorien, die in ihren Modellen auf 
unterschiedliche Aspekte fokussieren [4-7]. Die Frage, welche Organisationstheorie die 
Beste ist kann nicht beantwortet werden. Organisationstheorien repräsentieren Modelle 
und damit (nach Stachowiak) die zwar begründete, aber subjektive Sicht des Modellie- 
rers. Organisationstheorien setzen höchst unterschiedliche Schwerpunkte bei der Analyse 
von Organisationen und verfolgen unterschiedliche Zielsetzungen. Es gibt zu den jewei- 
ligen Organisationstheorien empirische Untersuchungen, die Ergebnisse zugunsten oder 
Ungunsten einer Theorie liefern. Allerdings sind die verwendeten Untersuchungs- sind 
Analysemethoden umstritten [7]. 

Organisationstheorien liegen bestimmte Menschenbilder zugrunde, und die Aus- 
gestaltung des Geschäftsprozessmanagements wird stark von dem in einer Organisa- 
tion herrschenden Menschenbild geprägt. Deshalb stellen wir mit dem Taylorismus, der 
Habermas’schen Theorie des kommunikativen Handelns, und den sozialen Systemen 
von Luhmann drei Organisationstheorien mit ihren Menschenbildern in den folgenden 


Abschnitten vor!. 


2.3.1 Taylorismus und Fordismus 


Der Taylorismus führte das Experiment in die Managementlehre und -praxis ein, 
und zählt zu den Klassikern der Organisationslehre. Mit dem sogenannten Scientific 
Management erhielten Organisationen ein Instrument zu ihrer effizienten Gestaltung. 
Ein wesentliches Kennzeichen ist die Trennung zwischen planender Kopfarbeit und aus- 
führender Handarbeit. Nach dem Tayloristischen Menschenbild sind Arbeiter dumm und 
faul und müssen deshalb strengen Regeln unterworfen werden. Diese Sicht beeinflusst 
auch heute noch oft implizit das Verhalten von Führungskräften. 

Für Frederik Winslow Taylor waren die wichtigsten Ziele die Vervollkommnung der 
Produktionsmittel und Arbeitsverfahren, straffere Organisation und Zeitordnung des 
Arbeitsablaufes im Betrieb, sowie eine Neuordnung des Entlohnungssystems. Ein Kern- 
element des Taylorismus ist die Gestaltung von Arbeitsprozessen auf der Grundlage 


!Ein Überblick über Organisationstheorien findet sich in [7]. 
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von Zeit- und Bewegungsstudien. Eine Zerlegung des Produktionsprozesses in kleinste 
Arbeitsschritte, eine Entlastung der Arbeiter von geistigen Tätigkeiten, sowie eine Ände- 
rung des Lohnsystems sollen zu einer optimalen Nutzung der vorhandenen Leistungs- 
potenziale führen. 

Ziel ist die Steigerung der Produktivität menschlicher Arbeit. Dies geschieht durch 
die Teilung der Arbeit in kleinste Einheiten, zu deren Bewältigung keine, oder nur 
geringe Denkvorgänge zu leisten, und die aufgrund des geringen Umfangs bzw. Arbeits- 
inhalts schnell und repetitiv zu wiederholen sind. 

Dem Taylorismus liegen folgende Kernprinzipien zugrunde: 


e Arbeitsplanung 
Die Planung der Arbeit wird von anderen Personen durchgeführt als deren 
Ausführung (Trennung von Hand- und Kopfarbeit). Damit wollte Taylor die 
Drückebergerei, die er den Arbeitern unterstellte, umgehen. Durch Zeit und 
Bewegungsstudien, die von den Kopfarbeitern ausgeführt wurden, sollte der geringste 
Bewegungs- und Zeitaufwand für einen Arbeitsschritt ermittelt werden. 

e Leistungslohn 
Aus diesen Zeit- und Bewegungsstudien ergab sich auch, was die Arbeiter in einer 
gewissen Zeit zu leisten hatten. Ein Bonus oder eine Prämie sorgten dafür, dass sich 
die als dumm und faul eingestuften Arbeiter auch tatsächlich bemühten, die vor- 
gegebenen Leistungsdaten zu erreichen. 

e Auswahl der am besten geeigneten Arbeiter 
Durch eine entsprechende Auslese galt es einen erstklassigen Arbeiterstamm auf- 
zubauen. Es wurden entsprechende Tests entwickelt und eingesetzt, um besonders 
fingerfertige und flinke Arbeiter zu identifizieren. 

e Versöhnung zwischen Arbeitern und Management 
Taylor glaubte, dass durch das von ihm entwickelte System die Produktivität so 
gesteigert werden kann, dass der Streit um die Verteilung des Gewinns zur Neben- 
sache werden würde. Dadurch sollte der Konflikt zwischen Arbeitgebern und Arbeit- 
nehmern aufgelöst werden. 


Der Taylorismus betrachtet im Wesentlichen die Strukturierung der Arbeitsschritte, stellt 
jedoch nicht auf deren Reihenfolge ab. Diesen Aspekt ging Henry Ford an, der mit der 
Einführung des Fließbands die einzelnen Tätigkeiten koordinierte. Damit waren die 
Voraussetzungen für die Massenfertigung geschaffen, die das 20. Jahrhundert prägte. 
Das Fließbandprinzip wurde auch in die Verwaltung übertragen und beeinflusste stark 
das Geschäftsprozessmanagement. Flussdiagramme sind die Fließbandvorgaben für die 
Abwicklung von Verwaltungsaufgaben oder die „Produktion“ von Dienstleistungen. 
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2.3.2 Kommunikatives Handeln nach Habermas 


Im Gegensatz zum Taylorismus geht die Theorie des kommunikativen Handelns nach 
Habermas von einsichtigen Menschen aus, die durch die Kommunikation untereinander 
zu einem gemeinsamen vernünftigen Handeln kommen. Mit seinem Gesellschaftsmodell 
erklärt Habermas die Vorgänge in einer Gesellschaft, wie z. B. die Suche nach Wahrheit, 
nach Gerechtigkeit. Es ist also ein Modell, das alle angeht, denn die Themen Wahrheit 
und Gerechtigkeit betreffen sämtliche Mitglieder von Gesellschaften. Der zentrale Aspekt 
im Gesellschaftsmodell von Habermas ist das sogenannte kommunikative Handeln. 

„Der Begriff des kommunikativen Handelns schließlich bezieht sich auf die Inter- 
aktion von mindestens zwei sprach- und handlungsfähigen Subjekten, die (sei es mit ver- 
balen oder extraverbalen Mitteln) eine interpersonale Beziehung eingehen. Die Aktoren 
suchen eine Verständigung über die Handlungssituation, um ihre Handlungspläne und 
damit ihre Handlungen einvernehmlich zu koordinieren“ [8]. 

Nach Habermas gelingt es durch Kommunikation, dass der einzelne Mensch, der von 
sich aus nicht vernunftbegabt ist, diesen Mangel überwindet. Die Kommunikation zwi- 
schen Menschen wird zum intersubjektiven Handeln und zu einer möglichen Quelle der 
Vernunft. Kommunikatives Handeln heißt Handeln auf der Grundlage der Verständigung 
zwischen Menschen. 

Habermas möchte damit Soziologen und Politikern ein Modell anbieten, das sie nutzen 
können, um die Gesellschaft zu analysieren bzw. zu gestalten. Dem einzelnen Menschen 
kann es dazu dienen, sich trotz der Komplexität heutiger Gesellschaften zurecht zu finden. 


2.3.3 Soziale Systeme nach Luhmann 


Ähnlich wie bei Habermas basiert das Gesellschaftsmodell von Luhmann auf Kom- 
munikation. Die Unterschiede liegen darin, in wieweit Kommunikation und Handeln 
kombiniert sind. Luhmann lässt ausschließlich Kommunikation als konstituierenden 
Aspekt für Organisationen zu — Kommunikation findet nicht zwischen Menschen statt, 
sondern zwischen mindestens zwei informationsverarbeitenden Prozessoren. Damit 
sieht Luhmann die Kommunikation abstrakter. Nach ihm besteht die Gesellschaft nicht 
aus Menschen oder Teilen von Menschen. Sonst würde man etwas von der Gesellschaft 
abschneiden, wenn man etwas vom Menschen abschneidet. Der Körper eines Men- 
schen (als biologisches System) mit einem Bewusstsein (psychisches System) ist zwar 
in vielen Fällen Voraussetzung für das Funktionieren eines sozialen Systems, also der 
Kommunikation, aber ein Mensch ist nicht das soziale System selbst. Luhmann macht 
in seiner Organisationstheorie keinerlei Aussagen zur Natur des Menschen, lässt also 
das Menschenbild offen. Menschen sind nur insofern Teil der Organisation, als sie mit- 
einander kommunizieren. 

Die Kommunikation zwischen den informationsverarbeitenden Prozessoren besteht 
aus den sogenannten Selektionen der Information, der Mitteilung und des Verstehens 
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Zwei informationsverarbeitende Prozessoren 
In der Regel Personen oder soziale Systeme 


Sender Empfänger 
Bei Luhmann: „Alter“ Bei Luhmann: „Ego“ 
Drei Selektionen: 1. Selektion der Information | 3. Selektion der Annahme/ des 
i 2. Selektion der Mitteilung Verstehens 


Abb. 2.2 Luhmann’sches Kommunikationsverständnis 


(siehe Abb. 2.2). Die ersten beiden Selektionen liegen beim Sender und die dritte beim 
Empfänger. Die Kommunikation als Stück mit mindestens zwei Akteuren in drei Akten 
ist eine unteilbare Einheit, nämlich die kleinste Einheit eines sozialen Systems und die 
elementare Operation der Gesellschaft [9]. Diese Sicht kann als Muster zur Definition 
der Kommunikation in Geschäftsprozessen dienen, vollkommen unabhängig von einem 
konkreten Menschenbild. 

Sowohl Luhmann als auch Habermas stellen in ihrer Organisationstheorie also die 
Kommunikation in den Mittelpunkt der Betrachtung. Dass diese beiden bedeutenden 
Organisationstheoretiker den Kommunikationsaspekt der Organisation so stark betonen 
und ihre Theorien weitreichend akzeptiert sind, kann als Indiz gelten, Geschäftsprozesse 
primär kommunikationsorientiert zu betrachten. 


2.3.4 Organisationen 


Komplexe soziale Systeme können in kleinere soziale System gegliedert werden. Diese 
Struktur eines komplexen sozialen Systems wird als Organisationsstruktur bezeichnet. 
Nach welchen Kriterien die Aufteilung in kleinere soziale System erfolgt ist subjektiv 
und hängt von den jeweiligen Absichten ab. Entsprechend der Luhmann’schen Definition 
eines sozialen Systems kommunizieren die einzelnen sozialen Systeme innerhalb eines 
komplexeren sozialen Systems. Organisationsstrukturen sind also ein Modell eines kom- 
plexeren sozialen Systems. 

In Abgrenzung zum weiten Verständnis des Begriffs Organisation bei Luhmann oder 
Habermas hat sich auch ein engeres Verständnis von Organisationen entwickelt. In der 
Betriebswirtschaft wird unter Organisation das formale Regelwerk eines arbeitsteiligen 
Systems verstanden. In der Organisationssoziologie bezeichnet sie eine besondere 
Form von sozialem Gebilde, die sich von anderen sozialen Gebilden wie beispielsweise 
Familien, Gruppen, Bewegungen oder Netzwerken unterscheiden lässt. Wesentliche 
Kennzeichen von Organisationen sind, dass Personen sich ihnen anschließen oder sie 
verlassen können. 

Darüber hinaus besitzen sie einen Zweck auf den hin sie sich ausrichten. Organisa- 
tionen haben Regelungen zur Arbeitsteilung wie Spezialisierung nach Verrichtung, 
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Funktion, Objekten oder Raum bzw. entsprechende Mischformen. Diese Arbeits- 
teilung erfordert die Koordination der einzelnen Tätigkeiten. Als zentrales Instru- 
ment der Koordination gilt in der Organisationslehre die Hierarchie. Die hierarchische 
Koordination wird ergänzt durch Stäbe, Kommissionen, Arbeitskreise etc. Bei ein- 
maligen oder erstmalig zu lösenden Problemen wird die Hierarchie durch eine Projekt- 
organisation ergänzt. 


2.4 Modelle der Betriebswirtschaft 


Betriebswirtschaftslehre ist die Lehre von den wirtschaftlichen, organisatorischen, tech- 
nischen sowie finanziellen Abläufen und Strukturen in Unternehmen. Damit ist auch das 
Geschäftsprozessmanagement ein Teil der Betriebswirtschaft. Denn Geschäftsprozesse 
dienen dazu die Wirtschaftlichkeit eines Unternehmens zu verbessern, und zwar mit 
all den zugehörigen Aspekten wie Kundenzufriedenheit, Mitarbeitermotivation, Ein- 
bindung von Partnern usw. Für die Strukturierung all dieser Aspekte und zur Analyse 
ihres Zusammenwirkens hat die Betriebswirtschaft Modelle entwickelt, die bei ihrer 
Anwendung in das Geschäftsprozessmanagement hineinwirken. 


2.4.1 Geschäftsmodell 


Ein Geschäftsmodell (Business Model) bezieht sich auf das Gesamtkonzept eines Unter- 
nehmens. Es repräsentiert modellhaft die Zusammenhänge, wie dieses für seine Kunden 
Mehrwert erzeugen und damit nachhaltig Erträge erzielen kann. Neben den angebotenen 
Produkten und Services geht es u. a. um die Struktur des Unternehmens, die Definition 
der Zielgruppen (Kunden) und deren Ansprache sowie um die Gestaltung der Geschäfts- 
prozesse. Über dieses Verständnis hinaus gibt es für den Begriff des Geschäftsmodells 
eine Reihe weiterer Definitionen [10]. 

Ein Geschäftsmodell dient folglich dazu, den Zusammenhang zwischen dem Unter- 
nehmen als Handlungssystem und der Wertschöpfung zu verstehen. Es spiegelt wider, 
wie eine Firma funktioniert und welche Werte sie für bestimmte Zielgruppen erzeugt. 
Geschäftsmodelle werden im Rahmen einer Unternehmensgründung oder einer Neuaus- 
richtung erstellt. Sie bestehen aus mehreren Teilmodellen, in denen beschrieben wird, 
welche Ressourcen (Materialien, Informationen usw.) einem Unternehmen als Ein- 
gangsgrößen zur Verfügung stehen (müssen), und wie diese Ressourcen bearbeitet und 
in vermarktungsfähige Produkte oder Dienstleistungen umgeformt werden, die dann zum 
Kunden transferiert werden, um entsprechende Einnahmen zu erzielen [11]. 

Geschäftsmodelle können mehreren Stakeholdern dienen. Die Unternehmensführung 
kann damit das eigene Geschäft besser verstehen, bestehende Stärken und Schwächen 
sowie Möglichkeiten zur Weiterentwicklung, Transformation und Verbesserung der 
Wettbewerbsposition erkennen. Für Investoren ist das Geschäftsmodell oft ein wichtiger 
Aspekt bei Anlageentscheidungen. 
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Zur Erstellung von Geschäftsmodellen wurde eine Reihe von Instrumenten ent- 
wickelt. Das bekannteste ist der Business Model Canvas von Alexander Osterwalder 
[12], der in den letzten Jahren große Akzeptanz fand. Wie der Name sagt, geht der Busi- 
ness Model Canvas-Ansatz von einem Plakat aus, auf dem die betrachteten Aspekte des 
Geschäftsmodells visualisiert werden. Der Canvas liefert ein Raster für neun Geschäfts- 
modellaspekte, welches mit den konkreten Ausprägungen der Aspekte für das betrachtete 
Unternehmen gefüllt wird (vgl. Abb. 2.3). Im Zentrum steht das Werteversprechen (Pro- 
dukt oder Dienstleistung). 

Beim Ausfüllen gilt es jeweils eine Reihe von Fragestellungen zu den neun Aspekten 
zu beantworten. Die folgenden Ausführungen erläutern die Aspekte kurz und geben eine 
Auswahl wichtiger dazugehöriger Fragen wieder. 


1. Kundensegmente, Zielgruppen: 
Alle Personen oder Organisationen, für die das betrachtete Unternehmen Werte kreie- 
ren will. 
Zu beantwortende Fragen sind u. a.: 
— Wer profitiert vom Produkt oder der Dienstleistung? 
— Welche Kunden sind besonders wichtig? 
2. Werteversprechen, Kundenutzen: 
Für jedes Kundensegment gibt es ein eigenes Werteversprechen, den Kundennutzen. 
Dies ist eine auf die Bedürfnisse des jeweiligen Segments abgestimmte Kombination 
aus Produkt und Dienstleistung. 
Zu beantwortende Fragen sind u. a.: 
— Welchen Nutzen bzw. Wert hat das Angebot für die Kunden? 
— Welche Kundenprobleme werden mit den angebotenen Produkten und/oder Dienst- 
leistungen gelöst? 


Schlüssel- Schlüssel- Werte- Kunden- Kunden- 
partner aktivitäten versprechen beziehungen | segmente 
Key Partners Key Activities Value Customer Customer 
Proposition Relationship Segments 
Schlüssel- Kanäle 
ressourcen 
Channels 

Key Ressources 
Kostenstruktur Einnahmequellen 
Cost Structure Revenue Streams 


Abb. 2.3 Schema des Business Model Canvas 
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3. Kanäle, Vertriebswege: 
Dieser Faktor steht für die einzelnen Kanäle, über die mit den Kunden kommuniziert 
wird und ihnen die versprochenen Werte übermittelt werden. Die Vertriebskanäle 
bestimmen, wie die Interaktion mit den Kunden abläuft. Kommunikation, Distribution 
und Verkaufsstellen bilden Schnittstellen eines Unternehmens zu seinen Kunden. 
Die Wahrnehmung des Kunden an diesen Berührungspunkten ist dabei zentral und 
bestimmt den Eindruck, den ein Kunde von einem Unternehmen hat. 
Zu beantwortende Fragen sind u. a.: 
— Wie erfahren Kunden von den angebotenen Produkten und Dienstleistungen? 
— Wie gelangen die Produkte/Dienstleistungen zum Kunden? 

4. Kundenbeziehungen: 
Hier wird beschrieben, welche Form des Umgangs mit den Kunden gepflegt wird. 
Jedes Unternehmen sollte sich darüber Gedanken machen, welche Arten von Kunden- 
beziehungen es mit den verschiedenen Zielgruppen eingehen möchte. Dabei hängt 
die Gestaltung der Kundenbeziehungen nicht nur von der jeweiligen Zielgruppe ab, 
sondern auch von den damit verbundenen Zielen des Unternehmens (Neukunden- 
gewinnung, Bestandskundenpflege etc.). 
Zu beantwortende Fragen sind u. a.: 
— Welche Art von Beziehung erwarten die einzelnen Kundengruppen? 
— Wie wird die Beziehung zu den Kunden organisiert? 
— Was kostet die Pflege des Kundenkontakts und was bringt dieser Kunde? 

5. Einnahmequellen, Erlösmodelle: 
Das Unternehmen schafft mit seinem Angebot einen Mehrwert. Die zentrale Frage 
ist, wie viel der Kunde bereit ist, dafür zu bezahlen. Das Unternehmen trifft eine 
Entscheidung bezüglich der Preismodelle und der Preisstrategie (Einmalzahlung, 
Abonnement etc.). 
Zu beantwortende Fragen sind u. a.: 
— Wofür und wie viel sind Kunden wirklich bereit für das Angebot zu zahlen? 
— Wie viel trägt jede der einzelnen Umsatzquellen zum Gesamtumsatz bei? 
— Wie würden die Kunden gerne zahlen? 

6. Schlüsselressourcen: 
Zur Erstellung des Angebots sind in jeder Unternehmung bestimmte Ressourcen 
erforderlich. Diese können sich im eigenen Besitz befinden, aber auch gemietet oder 
von strategischen Partnern zur Verfügung gestellt werden. 
Zu beantwortende Fragen sind u. a.: 
— Welche physischen Ressourcen (Räumlichkeiten, Produktionsmaschinen) werden 

benötigt, um ein Produkt oder einen Service erstellen und anbieten zu können? 
— Welche intellektuellen Ressourcen (Wissen, Patente, Partnerschaften, Kunden- 
stamm) werden benötigt? 

— Welche personellen Ressourcen (Team) werden benötigt? 
— Welche finanziellen Ressourcen (verfügbares Kapital, Sicherheiten) werden benötigt? 
— Wie können die nötigen Ressourcen beschafft und vorgehalten werden? 
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7. Schlüsselaktivitäten: 
Schlüsselaktivitäten sind die für die Leistungserstellung und -verwertung nötigen 
Tätigkeiten, z. B. Produktion, Vertrieb. 
Zu beantwortende Fragen sind u. a.: 
— Welche Schlüsselaktivitäten müssen ausgeführt werden, um ein Produkt oder einen 
Service anbieten und damit den Kundennutzen realisieren zu können? 
— Welche Aktivitäten für welche Vertriebskanäle? 
— Welche Aktivitäten für welche Kundenbeziehungen? 
8. Schlüsselpartner: 
Schlüsselpartner sind Geschäftspartner, die wichtige Ressourcen für die Realisierung 
des Geschäftsmodells bereitstellen. 
Mit ihnen gehen Unternehmen oft strategische Allianzen ein. Beispiele sind Lieferan- 
ten, Service Provider o. Ä. 
Zu beantwortende Fragen sind u. a.: 
— Wer sind Schlüsselpartner und was tun diese für das Unternehmen? 
— Welche Schlüsselressourcen werden von welchen Partnern zur Verfügung gestellt? 
9. Kostenstruktur: 
Die Kostenstruktur gibt Aufschluss über die wichtigsten Kostenfaktoren eines 
Geschäftsmodells. 
Zu beantwortende Fragen sind u. a.: 
— Was sind die größten und wichtigsten Kostenfaktoren in dem Geschäftsmodell? 
— Welche Schlüsselressourcen/Schlüsselaktivitäten sind die teuersten? 


Aus den einzelnen Feldern eines Geschäftsmodells lassen sich Kennzahlen und die 
zugehörigen Zielwerte für Geschäftsprozesse ableiten. Umgekehrt können die Kenn- 
zahlen und Zielwerte den Entwurf der Prozesse beeinflussen. Liegt der Fokus auf nied- 
rigen Preisen, werden Prozesse anders aussehen, als wenn das Geschäftsmodell eher auf 
hoher Qualität ausgerichtet ist. 


2.4.2 Balanced Scorecard 


Die Balanced Scorecard (BSC) wurde Anfang der 1990er-Jahre von Kaplan und Nor- 
ton vorgestellt [13]. Sie ist ein Bindeglied zwischen dem Geschäftsmodell, der Strategie- 
findung und deren Umsetzung. Unter Strategie werden in der Wirtschaft klassisch die 
(meist langfristig) geplanten Verhaltensweisen der Unternehmen zur Erreichung ihrer 
Ziele verstanden. 

Eine BSC beginnt bei der Vision und Strategie eines Unternehmens und definiert auf 
dieser Basis die kritischen Erfolgsfaktoren (KEF) mithilfe von Kennzahlen und dazu- 
gehörigen Zielwerten. Die Vision eines Unternehmens beschreibt das langfristige, ambi- 
tionierte Ziel, das eine Organisation bzw. Unternehmen anstrebt. Typische Visionen sind 
Formulierungen wie „Wir wollen Marktführer in unserem Marktsegment werden“ oder 
„Wir wollen das profitabelste Unternehmen in unserem Marktsegment werden“. 
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Die Kennzahlen fördern die Zielsetzung und Leistungsfähigkeit in kritischen 
Bereichen der Strategie, um die Vision zu erreichen. Die BSC ist daher ein Manage- 
ment-System, das aus der Vision als Teil des Geschäftsmodells und der Strategie zur 
Umsetzung des Geschäftsmodells abgeleitet wird, und die wichtigsten Aspekte des 
Unternehmens widerspiegelt. Das BSC-Konzept unterstützt strategische Planung und 
Implementierung durch eine Bündelung der Maßnahmen aller Einheiten eines Unter- 
nehmens auf der Basis eines gemeinsamen Verständnisses seiner Ziele und durch einen 
leichteren Zugang zur Bewertung und Fortschreibung der Strategie. 

Da traditionelles, rein auf finanzielle Kennzahlen aufgebautes Management den 
Anforderungen von Unternehmen im Informationszeitalter an effektive Planungswerk- 
zeuge nicht mehr genügt, haben Kaplan und Norton für die BSC vier Perspektiven ein- 
geführt, aus deren Blickwinkel die Aktivitäten eines Unternehmens umfassend bewertet 
werden können. Für jede Perspektive werden Ziele, Kennzahlen, Vorgaben und Maßnah- 
men definiert (vgl. Abb. 2.4). 


2.4.3 Total Quality Management und EFQM 


Der Begriff des Total Quality Management (TQM) steht für die Optimierung der 
Qualität von Produkten und Dienstleistungen eines Unternehmens in allen Funktions- 
bereichen und auf allen Ebenen durch Mitwirkung aller Mitarbeiter. Optimierung der 
Qualität bedeutet dabei, weder mit gegebenem Aufwand das höchste Qualitätsniveau zu 
erreichen, noch die Qualität ohne Rücksicht auf Kosten zu steigern. Vielmehr geht es 


Finanziell 


Wie sollen wir 
gegenüber Teil- 
habern auftreten, 
um finanziellen 
Erfolg zu haben? 


Interne Geschäftsprozesse 
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Abb. 2.4 Perspektiven der Balanced Scorecard [14] (Mit freundlicher Genehmigung von © 
Springer Fachmedien Wiesbaden GmbH 2010. All Rights Reserved) 
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darum, auf die Interessen des Kunden zu fokussieren und Qualität an der Erfüllung sei- 
ner Anforderungen festzumachen. 

Welche Anforderungen ein Unternehmen dabei an sich stellt, und durch welche Posi- 
tionierung gegenüber dem Kunden es sich den größten und nachhaltigsten Geschäftserfolg 
verspricht, entscheidet die Führung eines Unternehmens selbst. Diese Positionierung 
ist nicht statisch. Erkenntnisse zu Kundenwünschen und zu den Vorgehensweisen zur 
Erfüllung dieser Wünsche erfordern eine permanente Anpassung des Unternehmens. 

Um TQM zu etablieren bietet die European Foundation for Quality Management 
(EFQM) Organisationen Hilfestellung für den Aufbau und die kontinuierliche Weiter- 
entwicklung eines umfassenden Managementsystems. Abb. 2.5 zeigt die Struktur des 
EFQM-Ansatzes. Diese Struktur dient zum einen als Werkzeug, um ein TQM aufzu- 
bauen und zum anderen dazu, durch ein umfassendes Bewertungssystem Verbesserungs- 
potenziale zu ermitteln und den Geschäftserfolg zu steigern. 

Als Befähiger gelten im EFQM-Modell die Methoden und Konzepte, die eingesetzt 
werden, um die Ergebnisse zu erreichen, die in der rechten Hälfte der Abbildung dar- 
gestellt sind. Die Prozentwerte in der Darstellung geben an, in wieweit die einzelnen 
Aspekte in die Gesamtbewertung eines Unternehmens einfließen. 

Bei den Befähigern geht die EFQM davon aus, dass Prozesse den größten Einfluss auf 
die Ergebnisse auf der rechten Seite haben. Damit liefert das Modell gute Ansatzpunkte 
für die Identifikation von Kennzahlen und deren Zielwerte. 
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Abb. 2.5 EFQM-Struktur 
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Neben der Möglichkeit ein Managementsystem aufzubauen bietet EFQM auch ein 
sehr ausgefeiltes Konzept, dessen Stand der Entwicklung zu bewerten. Durch einen 
umfangreichen Fragekatalog kann eine Rundumbewertung einer Organisation erfol- 
gen. Die Bewertung kann durch Mitarbeiter der Organisation selbst oder durch externe 
Berater erfolgen. Die besten Organisationen in Europa erreichen bei einer solchen 
Bewertung rund 750 von maximal 1000 erzielbaren Punkten. 


2.4.4 EN ISO 9001 


Eine im Vergleich zu TQM abgeschwächte Form eines Qualitätsmanagements bil- 
det der Standard EN ISO 9001. Er beschreibt Minimalanforderungen an ein Qualitäts- 
managementsystem. Abb. 2.6 illustriert die Grundlagen des Standards. 

Die Verantwortung der Leitung bedeutet, dass diese definiert, welche Kunden- 
forderungen erfüllt werden und welche Qualitätspolitik dabei verfolgt wird. Die 
Umsetzung der Qualitätspolitik wird geplant und die entsprechenden Verantwortlich- 
keiten und Befugnisse in der Organisation dafür festgelegt. In der Verantwortung der 
Leitung liegt auch die Bewertung des QM-Systems in geplanten Abständen und ins- 
besondere unter Berücksichtigung der Kundenrückmeldungen. Die Unternehmens- 
führung muss außerdem die notwendigen Ressourcen wie Personal, Infrastruktur und 
eine adäquate Arbeitsumgebung bereitstellen. 

Den Kern eines EN ISO 9001 konformen QM-Systems bilden die Prozesse zur Reali- 
sierung der Produkte und der zugehörigen kundenbezogenen Dienstleistungen. Aufgaben 
umfassen die Planung und Definition von geeigneten Prozessen für die Entwicklung und 
Herstellung von Produkten, die Beschaffung von Inputs usw. Die Hilfsmittel zur Über- 
wachung der Produktherstellung und der Produktqualität müssen regelmäßig auf ihre 
Tauglichkeit überprüft werden. Die Ausführung der Prozesse muss durch Messungen 
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Abb. 2.6 EN ISO 9001 
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und Analysen von Kennzahlen laufend überwacht werden, um bei Abweichungen ent- 
sprechende Verbesserungsmaßnahmen einleiten zu können. 

EN ISO 9001 stellt also einen Rahmen für das Geschäftsprozessmanagement bereit. 
Die Ausführungen zeigen, dass es genau genommen keinen Unterschied zwischen 
Geschäftsprozess- und Qualitätsmanagement gibt. Ohne Geschäftsprozessmanagement 
gibt es kein Qualitätsmanagement und umgekehrt. 

Die vergleichsweise niedrigeren Anforderungen von EN ISO 9001 äußern sich in der 
Tatsache, dass ein Unternehmen mit einem (nur) EN ISO 9001-konformen Qualitäts- 
managementsystem etwa 300 Punkte bei einer EFQM Bewertung erreichen kann. 


2.4.5 Value Networks 


Das Konzept der Value Networks stammt von Verna Allee [15]. Unter einem Value Net- 
work versteht man Rollen und Personen, die untereinander sogenannte Tangibles und 
Intangibles austauschen. Tangible Wertflüsse sind materielle Wertflüsse zwischen Rollen 
und Personen und entsprechen dem Austausch von Waren, Dienstleistungen, Umsatz- 
erlösen usw. Tangible Wertflüsse repräsentieren Transaktionen, die auf Verträgen basie- 
ren. Intangible Wertflüsse sind ein Zusatznutzen durch den Fluss von Wissen, sie sind 
nicht vertraglich fixiert oder kostenpflichtig. Intangible Wertflüsse sind z. B. strategische 
Informationen, Planungswissen sowie bestehende emotionale Komponenten wie gegen- 
seitiges Vertrauen, gemeinsame Interessen, Wissensbedarf, Sicherheit usw. 

Value Networks sollen Beteiligten und Organisationsentwicklern durch die Sicht- 
barmachung und gestalterische Handhabung wechselseitiger tangibler und intangibler 
Leistungsflüsse (Transaktionen) befähigen, soziale und fachliche Bezüge von Interaktion 
in organisationalen Systemen mit zu bestimmen bzw. aktiv zu gestalten. Abb. 2.7 zeigt 
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Abb. 2.7 Schema eines Value Network 
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ein einfaches Value Network. Der Kunde gibt einen Wert Bestellung als einen tangiblen 
Wertfluss an den Lieferanten. Dieser tangible Wertfluss wird begleitet vom intangiblen 
Wertfluss Vertrauen. Der Kunde und die Logistikfirma sind mit dem tangiblen Wertfluss 
Lieferung verbunden usw. Die Nummern an den einzelnen Transaktionen drücken aus, in 
welcher Reigenfolge sie ausgeführt werden. 

Organisationen erbringen Leistungen als Ergebnis ihrer Aktivitäten, die schließ- 
lich zur Wertschöpfung eines Unternehmens oder einer Institution beitragen. Um 
diese Leistungen zu erfassen und sichtbar zu machen, empfiehlt sich eine austausch- 
orientierte Sicht auf Organisationen. Es ergibt sich dabei zumeist eine netzwerkartige 
Struktur, in der die Rollen innerhalb einer Organisation sowie deren Übertragungs- bzw. 
Kommunikationskanäle im Vordergrund stehen. Damit kann der Übergang zu einem 
kommunikationsorientierten Geschäftsprozessmanagement erfolgen. 


2.5 Modelle der Wirtschaftsinformatik 


Modelle der Wirtschaftsinformatik kombinieren Aspekte aus dem wirtschaftlichen und 
sozialen Bereich und der Informatik, um daraus Anforderungen für Informationssysteme 
abzuleiten. Die Modelle dienen überwiegend der Beschreibung von sozio-technischen 
Mensch-Maschine-Systemen. Die soziale Komponente deckt die Aspekte um die Mit- 
arbeiter und Partner ab. Die technische Dimension betrifft die Sachverhalte der Infor- 
matik. Wichtig ist dabei, dass entsprechende Modelle die Wechselwirkung zwischen den 
beiden Domänen betrachten, insbesondere die Mensch-Maschine-Interaktion. Im Gegen- 
satz zu rein technischen Systemen, die als deterministisch betrachtet werden, können 
sozio-technische Systeme aufgrund der Mitwirkung von sozialen Komponenten auch 
nicht-deterministisch, damit komplex, sein?. 

Wir beschränken uns hier auf die Behandlung von Frameworks für Unternehmens- 
architekturen und für IT-Management. Erstere entsprechen mit ihrer Verknüpfung der 
fachlichen und technischen Dimensionen von Organisationen genau dem Charakter der 
Wirtschaftsinformatik als Querschnittsdisziplin und sind von zentraler Bedeutung für das 
Prozessmanagement. 

Frameworks für das IT-Management beziehen sich im Wesentlichen auf das IT-Ser- 
vice-Management und damit verbundene Aspekte wie Governance und Compliance. Die 
bekanntesten Vertreter sind die IT Infrastructure Library (ITIL®) [17] und die Control 
Objectives for Information and related Technology (COBIT). Wegen seiner vergleichs- 
weise weiten Verbreitung in der Praxis gehen wir näher auf ITIL® ein und verweisen für 
weiterführende Informationen zu COBIT auf die einschlägige Website [18]. 


? Ausführliche Informationen zum Stand der Entwicklung und Forschung zum Thema Modell- 
bildung in der Wirtschaftsinformatik finden sich beispielsweise in Franz Lehner; Modelle und 
Modellierung in der Wirtschaftsinformatik- Versuch einer Standortbestimmung [16]. 
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2.5.1 Unternehmensarchitekturen 


Das Verständnis von Architektur im Kontext von Unternehmen deckt sich mit der 
ursprünglichen Bedeutung des Architekturbegriffs. Dieser bezeichnet in vielen Fach- 
gebieten die grundlegende Organisation eines Systems mit seinen Komponenten und 
deren Beziehungen zueinander und zu ihrer Umgebung. 

Konkret beschreibt und verknüpft eine Unternehmensarchitektur (Enterprise Archi- 
tecture), wie bereits in Abschn. 1.4 angesprochen, die fachlichen und technischen Ele- 
mente des Unternehmens. Letztere umfassen insbesondere die IT-Landschaft. Sowohl die 
Gesamtarchitektur als auch ihre Teile werden mit Modellen beschrieben. Die Palette der 
dafür eingesetzten Modelltypen reicht vom Geschäftsmodell über Organigramme, Daten- 
und Prozessmodelle auf der fachlichen Ebene bis hin zu Datenbankmodellen, Algorith- 
men und Programmen in der technischen Schicht. 

Wie für Geschäftsmodelle gibt es auch für die Modellierung von Unternehmensarchi- 
tekturen zahlreiche Rahmenwerke, die den Verantwortlichen Orientierung geben und 
die Arbeit erleichtern sollen. Dirk Matthes [19] hat mehr als 40 Frameworks mit unter- 
schiedlichem Detailierungsgrad, Schwerpunkt und Bekanntheitsgrad identifiziert. 

Wir beschränken uns auf die Behandlung von vier einschlägigen Vertretern: Das 
Zachman-Framework und The Open Group Architecture Framework (TOGAF) mit sei- 
ner Ergänzung Architecture-Animate (ArchiMate) wurden in Umfragen wesentliche 
Rahmenwerke genannt [19]. Die Architektur Integrierter Informationssysteme (ARIS) ist 
im deutschsprachigen Raum in der Praxis weit verbreitet und hat signifikante Bedeutung 
im Rahmen des Prozessmanagements. 


2.5.1.1 Zachman-Framework 

Das von John A. Zachman 1992 in seiner erweiterten Form vorgestellte Framework 
stellt ähnlich dem Business Modell Canvas ein Strukturraster dar, das der Anwender mit 
den Fakten für sein Unternehmen anreichern muss. Es besteht aus einer Matrix mit ver- 
schiedenen Perspektiven in den Zeilen und Abstraktionen zu jeder Perspektive in den 
Spalten. Abb. 2.8 zeigt eine verdichtete Darstellung, ein detailliertes Bild findet sich auf 
der Website von Zachman International’. 

Die Perspektiven in den Zeilen haben folgende Bedeutung: 


e Planer: Zielsetzung des Unternehmens, externe Anforderungen und Einflüsse, Geschäfts- 
modell 

e Besitzer: Anforderungen an Daten, Abläufe, Strukturen usw. zur Unternehmensführung 

e Designer: Systementwurf und Systemstruktur zur Umsetzung der Anforderungen 


3www.zachman.com. 
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e Builder: Umsetzung des Systementwurfs 
e Programmierer: Bereitstellen der technischen Infrastruktur 
e Benutzer: Betriebsverantwortliche zur Sicherstellung der Funktionsfähigkeit 


In den Spalten finden sich die Fragen, die das Unternehmen beantworten muss: 


e Was (Inventar): Was für Objekte, Ausrüstungen, Daten, Informationen etc. werden 
benötigt? 

e Wie (Funktionen und Prozesse): Wie arbeitet das Unternehmen, z. B. wie sehen die 
Geschäftsprozesse aus? 

e Wo (Standorte, Netzwerk); Wo sind die Standorte des Unternehmens? 

e Wer (Menschen): Wer sind die Menschen, die das Unternehmen am Laufen halten? 
Welche Geschäftseinheiten gibt es und wie sieht die Organisationsstruktur aus? 

e Wann (Zeit): Wann werden Geschäftsprozesse instanziiert und ausgeführt? Was sind 
die Zeitpläne für das Geschäft? 

e Warum (Motivation): Warum betreiben wir das Geschäft so wie wir es betreiben? Was 
sind die Treiber des Geschäfts? Hier fließen Aspekte des Geschäftsmodells ein. 


Zachman sieht vor, dass für jede Zelle der Tabelle ein geeignetes Modell entwickelt 
wird. So gesehen handelt es sich bei seinem Framework um ein Modell für eine Menge 
von Modellen, die verschiedene Aspekte eines Unternehmens genauer betrachten. 

Die Nutzer können bei den Reihen und Spalten durch andere Schwerpunktsetzung 
vom Original abweichen. Diese Flexibilität ist eine Stärke des Modellrahmens. Er ent- 
hält aber keine Vorgehensweise oder Methodik zur Definition einer konkreten Unter- 
nehmensarchitektur. Prozesse für deren Entwicklung oder Transformation müssen sich 
die Anwender anderweitig erschließen oder gänzlich selbst gestalten. 


2.5.1.2 The Open Group Architecture Framework (TOGAF) 

TOGAF ist das Rahmenwerk der Open Group zur Entwicklung von Unternehmensarchi- 
tekturen einschließlich der Geschäftsprozesse. Während das Zachman-Framework die zu 
betrachtenden Objekte betont und kaum Unterstützung für den Architekturentwicklungs- 
prozess bietet, fokussiert TOGAF auf die Vorgehensweise zur Modellerstellung. Es stellt 
Methoden und Werkzeuge zur Verfügung, die bei Einführung, Erstellung, Gebrauch und 
Weiterentwicklung von Unternehmensarchitekturen helfen. 

TOGAF unterscheidet bei der Beschreibung vier Teilarchitekturen: 


e Business Architecture 
Fachliche Aspekte der Unternehmensarchitektur 
e Data Architecture 
Logische und physische Strukturen der Daten und Ressourcen für deren Management. 
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e Application Architecture 
Verwendete Anwendungssysteme und deren Beziehungen untereinander sowie ihre 
Relevanz für das Geschäft des Unternehmens. 

e Technology Architecture 
Anforderungen an die Software und Hardware für das Management der Daten und die 
Ausführung der Anwendungssysteme. Dies schließt z. B. Laufzeitumgebungen, Netz- 
werke, Middleware und sonstige Betriebsinfrastrukturen ein. 


Das TOGAF-Rahmenwerk setzt sich aus folgenden Komponenten zusammen: 


e Architecture Development Method (ADM) 
Methode und Vorgehensweise zur Entwicklung einer Unternehmensarchitektur 

e ADM Guidelines and Techniques 
Satz von Hilfsmitteln und Richtlinien, die die Anwendung des ADM unterstützen 
(z. B. Hilfsmittel für die iterative Verwendung des ADM) 

e Architecture Content Framework 
Strukturmodell um die Ergebnisse, die mit dem ADM erzeugt werden, einheitlich und 
konsistent zu definieren, strukturieren und darzustellen 

e Enterprise Continuum 
Modell zur Strukturierung eines möglichen Repository, das die jeweiligen 
Architekturen und die möglichen Lösungen wie Modelle, Muster, Architektur- 
beschreibungen etc. enthalten kann 

e Reference Models 
Grundmodelle, an denen sich spezifische Modelle für ein Unternehmen orientieren 
können. Dies sind das Technical Reference Model (TRM) und das Integrated Infor- 
mation Infrastructure Model 

e Architecture Capability Framework 
Verschiedenen Referenzmaterialien für die Entwicklung bestimmter Architekturm- 
odelleDie Architecture Development Method (ADM) bildet als iteratives Prozess- 
modell den Kern von TOGAF (vgl. Abb. 2.9). Damit werden alle Architekturartefakte 
erzeugt. ADM kann auf mehreren Ebenen angewendet werden, sodass die Architekten 
unterschiedliche Detailierungsstufen der Unternehmensarchitektur definieren können. 
Mithilfe der anderen Komponenten werden die Ergebnisse dann beschrieben, struktu- 
riert und abgelegt. 

e Die Phasen der ADM sind: 
Verschiedenen Referenzmaterialien für die Entwicklung bestimmter Architekturm- 
odelleDie Architecture Development Method (ADM) bildet als iteratives Prozess- 
modell den Kern von TOGAF (vgl. Abb. 2.9). Damit werden alle Architekturartefakte 
erzeugt. ADM kann auf mehreren Ebenen angewendet werden, sodass die Architekten 
unterschiedliche Detailierungsstufen der Unternehmensarchitektur definieren können. 
Mithilfe der anderen Komponenten werden die Ergebnisse dann beschrieben, struktu- 
riert und abgelegt. 
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Abb. 2.9 Architecture Development Method von TOGAF 


e Vorbereitungsphase (Preliminary Phase) 
Hier werden das organisatorische Umfeld und die verwendeten Rahmenwerke, 
Methoden, Unterstützungswerkzeuge sowie wichtige Prinzipien festgelegt. 

e Phase A Architekturvision (Architecture Vision) 
Hier werden die Ziele und die Beteiligten bei der Aktualisierung der Unternehmens- 
architektur festgelegt und eingebunden. 

e Phase B Geschäftsarchitektur, Geschäftsmodell (Business Architecture) 
Hier werden für die Geschäftsarchitektur der aktuelle und der gewünschte Zustand 
beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Es werden 
die gewünschten Sichten festgelegt und die dazu geeigneten Werkzeuge ausgewählt. 

e Phase C IS-Architektur (Information System Architecture) 
Hier werden für die Anwendungs- und Informations-/Daten Architektur der aktuelle 
und der gewünschte Zustand beschrieben. Die entscheidenden Unterschiede werden 
herausgearbeitet. Dazu werden die konkreten Anwendungen und Datenmodelle ver- 
wendet. 

e Phase D Technologiearchitektur (Technology Architecture) 
Hier werden für die Technologiearchitektur der aktuelle und der gewünschte Zustand 
beschrieben. Die entscheidenden Unterschiede werden herausgearbeitet. Dazu werden 
die konkreten Hardwaresysteme beschrieben. 
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e Phase E Möglichkeiten und Lösungen (Opportunities and Solutions) 
Hier werden die Vorhaben festgelegt, welche die Transformation aus der Ist-Situation 
zum Sollzustand durchführen. 

e Phase F Migrationsplanung (Migration Planning) 
Hier wird die Überführung von einem Ist-Zustand in einen Sollzustand geplant. 

e Phase G Implementierungsregeln (Implementation Governance) 
Hier wird die Implementierung in den Sollzustand durchgeführt und überwacht. 

e Phase H Änderungsmanagement (Architecture Change Management) 
Hier werden Anforderungen und externe Einflüsse gesammelt, welche dann als 
Grundlage für den nächsten Durchlauf des ADM dienen. 

e Anforderungen (Requirements Management) 
Das Anforderungsmanagement treibt den ADM-Prozess kontinuierlich und steht des- 
halb im Zentrum. 


2.5.1.3 Architecture-Animate (ArchiMate) 

Architecture-Animate, kurz ArchiMate*, ist die Bezeichnung einer von der Open Group 
veröffentlichten offenen und unabhängigen Modellierungssprache für Unternehmens- 
architekturen. Sie bietet Instrumente, die es Enterprise-Architekten ermöglichen, die 
Beziehungen zwischen Geschäftsbereichen und deren Entwicklung zu beschreiben, zu 
analysieren und zu visualisieren. 

Die ArchiMate-Sprache ermöglicht die Beschreibung der Struktur und des Ablaufs 
von Geschäftsprozessen, von Örganisationsstrukturen, Informationsflüssen, IT-Sys- 
temen und der technischen Infrastruktur. Die Beschreibungen helfen den Beteiligten, 
Veränderungen von Architekturelementen und deren Beziehungen zu konzipieren, die 
Folgen zu bewerten und zu kommunizieren. Abb. 2.10 zeigt das ArchiMate-Rahmen- 
werk. 

Die ersten drei Spalten entsprechen den Grundkonzepten von ArchiMate: 


e Passive Strukturelemente (Passive structure elements) 
Passive Strukturelemente sind die Objekte, auf denen die Aktionen aus dem Verhalten 
(Verhaltenselemente) ausgeführt werden. Im Allgemeinen sind dies Informations- 
objekte, aber auch physikalische Objekte können als passive Strukturelemente model- 
liert werden. 

e Aktive Strukturelemente (Active structure elements) 
Aktive Strukturelemente sind Elemente, die Handlungen ausführen können. Beispiele 
sind Menschen, Anwendungen, Rechnerknoten o. Ä. Die Handlungen können über 
Schnittstellen (Interfaces) angestoßen werden, die auch die Ergebnisse zur Verfügung 
stellen. 


Ahttp://www.opengroup.org/subjectareas/enterprise/archimate-overview. 
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Abb. 2.10 ArchiMate Architectural Framework 


e Verhaltenselemente (Behavior elements) 
Verhaltenselemente repräsentieren die dynamischen Aspekte eines Unternehmens. 
Ein Service ist das von außen sichtbare Verhalten des Systems, das diesen Service 
erbringt. Die Services werden über die entsprechenden Schnittstellen verwendet. 
Schnittstellenereignisse stoßen die aktiven Strukturelemente an, welche dann die 
zugehörige Servicefunktion ausführen. 


Diese drei Modellfragmente entsprechen den Grundelementen von natürlichen Spra- 
chen: Subjekt, Prädikat bzw. Verb und Objekt. Sie werden auf insgesamt sechs Ebenen 
betrachtet: 


e Strategieebene (Strategy Layer) 
In der Motivation wird beschrieben, was ein Unternehmen erreichen möchte. In den 
Strategiekonzepten wird auf übergeordneter Ebene beschrieben wie ein Unternehmen 
seine Ziele erreichen möchte. 

e Geschäftsebene (Business Layer) 
Mit den Elementen des Business Layer können Produkte und Services beschrieben 
werden, die ein Unternehmen extern zur Verfügung stellt. Die Geschäftsebene zeigt, 
wie das Unternehmen diese Produkte und Services realisiert und soll bei der Analyse 
der Unternehmensstruktur helfen. 

e Applikationsebene (Application Layer) 
In der Anwendungsebene wird die Unterstützung der Geschäftsebene durch 
Anwendungen und Daten dargestellt. 

e Technologieebene (Technology Layer) 
Auf der Technologieebene wird die Infrastruktur beschrieben, welche benötigt wird, 
um Anwendungen zu realisieren. Dies sind im Wesentlichen die benötigten Hardware- 
und Softwarekomponenten. 


44 2 Modelle 


e Physikalische Ebene (Physical Layer) 
In dieser Ebene wird auf das Zusammenwirken von IT und den physischen Kompo- 
nenten wie Maschinen, Sensoren und Aktoren fokussiert. 

e Implementierung und Migration (Implementation and Migration Layer) 
Das Implementierungs- und Migrationskonzept beschreibt, wie eine definierte Archi- 
tektur realisiert werden soll. Insbesondere werden darin die Arbeitspakete für die 
Umsetzung beschrieben. 


Die Zellen der Tabelle enthalten also die Kernelemente für die aktiven und passiven 
Strukturen sowie für das Verhalten auf der jeweiligen Ebene. 

Die Spalte Motivation beschreibt die Gründe für den Entwurf oder die Änderung 
eines Unternehmensmodells. Diese beeinflussen die Modellbildung und geben ihr die 
entsprechende Richtung. 

ArchiMate wird als Ergänzung und Konkretisierung von TOGAF gesehen. TOGAF 
beschreibt den Prozess für die Definition und Beschreibung einer Unternehmensarchi- 
tektur (Unternehmensmodell), allerdings enthält es keine Beschreibungssprachen 
für die jeweiligen Teilmodelle. ArchiMate soll diese Lücke schließen. Es bietet neben 
dem gezeigten Rahmenwerk für die zu entwickelnde Architektur auch Sprachen, um 
die Aspekte in den einzelnen Ebenen auszudrücken. Abb. 2.11 zeigt wie die einzelnen 
Schritte in der Architecture Development Method von TOGAF mit den Schichten von 
ArchiMate zusammenhängen. 


A 
Architektur 
Vision 
B 

Geschäfts- Business Layer 
architektur 
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tierungs- 
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Abb. 2.11 Zusammenhang von ArchiMate-Ebenen und TOGAF ADM 
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2.5.1.4 Architektur Integrierter Informationssysteme (ARIS) 

Die Architektur integrierter Informationssysteme (ARIS) ist ein Rahmenwerk zur Defi- 
nition von Unternehmensmodellen. Es umfasst die Daten-, Funktions-, Organisations-, 
Steuerungs- und Leistungssicht. Für jede Sicht sieht ARIS eine Reihe von Modelltypen 
für die Dokumentation vor. 


e Datensicht: 
Die Datensicht umfasst die betriebswirtschaftlich relevanten Geschäfts- oder 
Informationsobjekte und deren Beziehungen untereinander, das heißt alle Daten, die 
im Zusammenhang mit den Aktivitäten eines Unternehmens stehen. Informations- 
objekte umfassen sowohl Zustände wie Artikel- oder Kundenstatus als auch Ereig- 
nisse wie „Kundenauftrag ist eingetroffen“ oder „Fertigungsauftrag wurde ausgelöst“. 
Einschlägiger Modelltyp ist das Entity Relationship Model (ERM). 

e Funktionssicht: 
Die Funktionssicht beschreibt die betriebswirtschaftlich relevanten Tätigkeiten (Funk- 
tionen, Aktivitäten) sowie ihre hierarchischen Beziehungen. Untergeordnete Funk- 
tionen sind Teilfunktionen der übergeordneten Funktion. Die Funktionen führen 
Operationen auf den in der Datensicht beschriebenen Objekten aus. Funktionen wer- 
den in der Praxis mit Funktionsbäumen modelliert. 

e Örganisationssicht: 
In der Organisationssicht wird die Organisationsstruktur, das heißt die personel- 
len Ressourcen, eines Unternehmens und deren typischerweise hierarchischen 
Beziehungen in einer Aufbauorganisation modelliert. Das Organigramm ist hierfür als 
Modelltyp üblich. 

e Steuerungssicht: 
Die Steuerungssicht stellt den zeitlich-sachlogischen Zusammenhang zwischen 
den einzelnen betrieblichen Tätigkeiten her. Sie führt die Daten-, Funktions- und 
Organisationssicht zusammen und nimmt damit eine zentrale, integrierende Rolle ein. 
Die Steuerungsschicht wird deshalb auch Prozesssicht genannt. Wesentlicher Modell- 
typ ist die Ereignisgesteuerte Prozesskette (EPK). 

e Leistungssicht: 
In der Leistungssicht werden die Eingaben und Ergebnisse des beschriebenen 
Geschäftsprozesses in der Regel mithilfe von Produktbäumen beschrieben. 


Die Sichten, dafür typische Modelltypen und ihr Zusammenhang sind in Abb. 2.12 dar- 
gestellt. Das Bild macht auch deutlich, dass ARIS mit der integrierenden Steuerungssicht 
die Geschäftsprozesse, insbesondere mit der Abfolge der Aktivitäten, in den Mittelpunkt 
der Betrachtung stellt. 

Orthogonal zu der durch die Sichten vorgenommenen Strukturierung differenziert 
ARIS in Anlehnung an das Software Engineering die Abstraktionsebenen Fachkonzept, 
DV-Konzept und Implementierung. Dies zeigt die Nähe der mit ARIS entwickelten 
Modelle zur Informationstechnik. Für die Lösung einer betrieblichen Problemstellung 
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Abb. 2.12 Sichten und einschlägige Modelltypen in ARIS 


wird ein fachliches Modell erstellt und in ein entsprechendes DV-Konzept (DV-Modell) 
überführt. Dieses dient schließlich als Basis für die konkrete technische Umsetzung. 


e Fachkonzept: 
Im Fachkonzept werden die Sachverhalte der betrieblichen Problemstellung 
beschrieben. Auf dieser Ebene werden Datenmodelle, Funktionsmodelle, Organi- 
gramme, Wertschöpfungsketten bzw. Ereignisgesteuerte Prozessketten (EPKs) und 
Produktmodelle eingesetzt. 

e DV-Konzept: 
Im DV-Konzept wird spezifiziert, wie das Fachkonzept DV-technisch umzusetzen ist. 
Auf dieser Ebene werden Datenbankmodelle (Datensicht), Struktogramme (Funktions- 
sicht), Netztopologien (Organisationssicht) und Trigger-Mechanismen (Steuerungs- 
sicht) betrachtet. Der Zweck des DV-Konzepts ist eine Anpassung des Fachkonzepts an 
die Anforderungen der Informationstechnik. 

e Implementierung: 
Auf dieser Ebene wird das DV-Konzept in ein ausführbares Softwaresystem 
umgesetzt. Auf dieser Abstraktionsstufe werden Datenbeschreibungssprachen (Daten- 
sicht), Programme (Funktionssicht), Netzwerkprotokolle (Organisationssicht) und die 
Programmsteuerung (Steuerungssicht) betrachtet. 
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2.5.2 Framework für IT-Service-Management: ITIL’ 


Die IT Infrastructure Library (ITIL®) ist eine Sammlung vordefinierter Prozesse, Funk- 
tionen und Rollen, wie sie typischerweise in jeder IT-Infrastruktur mittlerer und großer 
Unternehmen vorkommen. Die praktische Zuweisung der Tätigkeiten erfolgt anhand von 
Rollen und Funktionen. Es handelt sich dabei um Good-Practice-Vorschläge, die an die 
Bedürfnisse des Unternehmens angepasst werden müssen. Inzwischen wurde die Samm- 
lung ergänzt durch ISO 20.000:2005, ein ITIL®-basiertes Zertifizierungsmodell für 
Organisationen. 

ITIL® umfasst fünf Kernbände mit derzeit insgesamt 37 Kernprozessen. Abb. 2.13 
zeigt die Struktur von ITIL®. Die fünf Kernbände orientieren sich am Service Live 
Cycle. Ausgehend von der Servicestrategie mit den Prozessen Strategiefindung, 
Finanzmanagement, Serviceportfoliosteuerung und Nachfragesteuerung wird über die 
Prozessgruppen der Serviceentwicklung und der Serviceinbetriebnahme schließlich die 
Dienstleistung mit den Prozessen der Gruppe Serviceerbringung erbracht. Die Prozedu- 
ren unterliegen der permanenten Verbesserung. 

Weitere Bücher wie „Software Asset Management“, „Small-Scale Implementation“ 
oder „Building an ITIL®-based Service Management Department“ ergänzen die Kern- 
publikationen. Damit bietet ITIL® umfassende Unterstützung bei der Entwicklung eines 
Prozesssystems für den IT-Bereich einer Organisation. 
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e 7-stufiger Verbesserungsprozess 
e Servicemessung 


e Serviceberichterstattung Sernvicestrateni 
ervicestrategie: 


« Strategiefindung 

e Finanzmanagement 

« Serviceportfoliosteuerung 
. 


Nachfragesteuerung Serviceentwicklung: 


Servicekatalog-Management 

Service Level Management 
Kapazitätsmanagement 
Verfügbarkeitsmanagement 

IT Service Notfallmanagement 
Informationssicherheitsmanagement 
Lieferantenmanagement 


Serviceerbringung: 
e Ereignissteuerung 


Störungsmanagement 
Anfrageerfüllung 
Problemmanagement 
Zugriffsmanagement 


Serviceinbetriebnahme: 
Inbetriebnahme und -unterstützung 
Änderungsmanagement 
Inventar- und Konfigurationsmanagement 
Versions- uns Übernahmemanagement 
Serviceüberprüfung und Test 
Wissensmanagement 


Abb. 2.13 ITIL®-Prozessgruppen 
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2.6 Modelle der Informatik 


Modelle der Informatik beziehen sich auf Datenstrukturmodelle und Abläufe in 
Computersystemen sowie wesentliche Aspekte wie Sicherheit, Robustheit etc. 

Diese Modelle dienen zum einen zur Abbildung eines betrachteten Realitätsaus- 
schnitts, um eine Aufgabe mithilfe der Informationsverarbeitung zu lösen. Sie beziehen 
sich auf ein abgegrenztes Problemfeld oder bestimmte Einsatzbereiche von Computer- 
systemen. Hierunter fallen Modelle, die Daten und die darauf ablaufenden Operationen 
im Fokus haben, sowie Modelle, die mehr die Gesamtstruktur von komplexen Program- 
men, also deren Architektur, betrachten. Diese beiden Modellkategorien werden auch 
Modelle zum Programmieren im Kleinen bzw. Modelle zum Programmieren im Großen 
genannt. 

Neben diesen zentralen Modellkategorien der Informatik gibt es weitere Modelle, die 
flankierende Aspekte betrachten, wie Zugriffsmodelle, Sicherheitsmodelle usw. Diese sind 
nicht Gegenstand der weiteren Ausführungen. Vielmehr erläutern wir in den folgenden 
Abschnitten einige für das Geschäftsprozessmanagement wesentliche Modellkonzepte. 


2.6.1 Information 


Information ist der zentralere Aspekt der Datenverarbeitung, die deshalb auch 
Informationstechnologie oder IT genannt wird. Information und Informationssysteme 
sind Modelle, die ein Objekt der realen Welt gemäß den Vorstellungen eines oder meh- 
rerer Subjekte repräsentieren. Die Vorstellungen des Subjekts orientieren sich dabei 
am beabsichtigten Verwendungszweck. Beispielsweise werden Gegenstände in einem 
Lager durch ihre Eigenschaften beschrieben wie Teilenummer, Maße, Gewicht usw. 
Verschiedene Anwender verwenden unterschiedliche Ausschnitte aus dem Modell: Der 
Einkauf blickt auf Informationen wie Einkaufspreis und Bestellgrenze, während den 
Lagerarbeiter eher die Maße und der Lagerplatz interessieren. 

Die Modellierung der Objektrealität kann deshalb als Interpretation durch die ver- 
wendenden Handelnden (Subjekte) wie Einkauf oder Lagerist verstanden werden. Infor- 
mation ist dann das Ergebnis und der Grund einer Interpretation; Sie kann aber auch 
selbst wiederum Objekt und damit Interpretations- und Modellierungsgegenstand sein. 
Dieses Verhältnis zwischen Subjekt, Information (Modell) und Original ist in Abb. 2.14 
dargestellt: 

Information erhält ihren Wert durch die Interpretation des Gesamtgeschehens durch 
die betrachtenden Subjekte. Diese Betrachtung läuft teils bewusst, größtenteils aber 
unbewusst ab. Die Informationsmenge wird dabei reduziert und dem jeweiligen Erkennt- 
nisinteresse entsprechend gefiltert oder mit anderen Informationen verknüpft. 

Daten unterscheiden sich von Informationen. Ein Datum (Einzahl von Daten) stellt 
zunächst nur eine Folge von Zeichen dar, deren Bedeutung nicht eindeutig ist. Die Zei- 
chen können z. B. Zahlen, Buchstaben oder Symbole sein. In der Marketingabteilung 
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eines Online-Shops findet sich beispielsweise die Zahlenfolge 0815. Diese Abfolge 
von Zeichen stellt zwar ein Datum dar, die Bedeutung ist allerdings nicht bekannt. Die 
Zeichenfolge selbst hat keine Bedeutung mit Ausnahme ihrer einzelnen Elemente. 

Aus diesem Datum können aber Informationen entstehen, wenn bekannt ist, in wel- 
chem Kontext es steht. Durch eine Kombination mit anderen Daten wird eine Beziehung 
hergestellt, die interpretiert werden kann und Information entstehen lässt. Steht das 
Datum 0815 im Kontext „Kunde Max Muster, Artikel 0815“ kann die Marketingab- 
teilung interpretieren, dass der Kunde Max Mustermann einen Artikel mit der Nummer 
0815 bestellt hat. 

Die Ergänzungen von Daten mit anderen Daten hängen vom Erkenntnisinteresse bzw. 
Nutzungsabsichten eines Subjekts ab. Ein Subjekt möchte mit den jeweils hergestellten 
Informationen meist einen Adressaten beeinflussen, z. B. zu einer Handlung bewegen. 
Information ist somit zu verstehen als „Aussagen, die den Erkenntnis- bzw. Wissensstand 
eines Subjektes (Informationssubjekt/-benutzer) über ein Objekt (Informationsgegen- 
stand) in einer gegebenen Situation und Umwelt (Informationsumwelt) zur Erfüllung 
einer Aufgabe (Informationszweck) verbessern“ [20] (vgl. Abb. 2.14). Die Modell- 
bildung ist demnach ein Teil des Informationsmanagements. 

Informationen sind wichtig für Politiker, Führungskräfte in der Wirtschaft aber auch 
für jeden Bürger dieser Welt. Sie geben einen bestimmten Sachverhalt, der zu einem 
bestimmten Zeitpunkt galt, wieder und erlauben in der Regel eine Fortschreibung in die 
Zukunft. Sie dienen dazu politische, wirtschaftliche oder persönliche Entscheidungen zu 
treffen. Bei der Nutzung von Informationen stellt sich immer die Frage, wer sie erzeugt 
hat und welche Absichten derjenige damit verfolgt. Hier spielt folglich die Subjektivität 
von Modellen eine wesentliche Rolle. 


2.6.2 Entity-Relationship-Modell 
Um aus Daten Informationen zu generieren, müssen diese wie gezeigt mit anderen Daten 


kombiniert und die entsprechenden Beziehungen beschrieben werden. Dadurch entsteht 
ein Datenmodell. Die bekannteste Methode für die Beschreibung von Datenmodellen ist 


ER eo di Zwecks 
; oden tur die Beeinflußung des 
Subjektive Sicht Zwecke des Subjekts Adressaten 


Informationen Adressat A 
= Modell 


Wirklichkeit 


Abb. 2.14 Information ist „Modell-wovon-wozu-für wen“ [21] 
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Abb. 2.15 Beispiel für ein Entity-Relationship-Diagramm 


das Entity Relationship Model (ERM). Ein Entity-Relationship-Modell setzt sich aus 
drei Hauptelementen zusammen: 


e Entitäten 
Entitäten sind die Objektklassen, die in dem interessierenden Ausschnitt der realen 
Welt betrachtet werden. 
e Beziehungen oder Relationen 
Relationen beschreiben die Beziehungen zwischen Entitäten. 
e Attribute 
Attribute sind Eigenschaften innerhalb des Kontexts einer Entität. 


Abb. 2.15 zeigt ein Beispiel für ein ERM. Aus ihm geht auch hervor, mit welchen Sym- 

bolen die Hauptelemente in der Regel ausgedrückt werden. Man findet jedoch auch 

ERM-Darstellungen mit Notationselementen der Unified Modeling Language (UML). 
Das Diagramm beschreibt den folgenden Sachverhalt: 


e Ein Mitarbeiter hat einen Namen. Ein Projekt hat einen Namen, einen Beginn, ein 
Ende und ein Budget. Die sogenannte Kardinalität drückt aus, dass ein Mitarbeiter 
mehrere Projekte leiten kann, aber ein Projekt nur von genau einem Mitarbeiter 
geleitet werden kann. 


Im Modellierungskonzept der Klassifikation werden Objekte zu Objekttypen (entity 
sets), und Beziehungen zu Beziehungstypen (relationship sets) zusammengefasst. Diese 
Typen unterscheiden sich nach: 


e Entitätstyp: Typisierung gleichartiger Entitäten (z. B. Mitarbeiter, Projekt) 

e Beziehungstyp: Typisierung gleichartiger Beziehungen (z. B. Mitarbeiter leitet Projekt) 

e Attributtyp: Typisierung gleichartiger Eigenschaften (z. B. Name für den Entitätstyp 
Mitarbeiter). Attribute oder Attributkombinationen, deren Wert(e) eine Entität ein- 
deutig identifizieren, heißen identifizierende(s) Attribut(e) (z. B. identifiziert das Attri- 
but Projektname den Entitätstyp Projekt) 
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Abb. 2.16 Häufige Symbole in Flussdiagrammen 


Zur Beschreibung besonderer Sachverhalte wie z. B. der angesprochenen Kardinalität 
umfassen ERMs noch weitere Konstrukte®. 


2.6.3 Fluss- oder Ablaufdiagramme 


Fluss- oder Ablaufdiagramme veranschaulichen eine Ausführungsreihenfolge von Tätig- 
keiten bzw. Aktionen und werden in zahlreichen Anwendungsbereichen verwendet. Sie 
können beschreiben, in welcher Reihenfolge Handlungen von Menschen oder anderen 
Akteuren ausgeführt werden sollen. Algorithmen oder Computerprogramme werden oft 
in Form von Flussdiagrammen (z. B. Programmablaufplänen) dokumentiert. Wegen der 
verbreiteten Anwendung von Flussdiagrammen haben sich zahlreiche Varianten heraus- 
gebildet, die spezielle Sachverhalte des jeweiligen Anwendungsbereichs berücksichtigen. 
Für die Datenverarbeitung wurde die Symbolik für Flussdiagramme in den Standards 
DIN 66.001:1983-12 bzw. ISO 5807:1985 festgelegt. Abb. 2.16 und 2.17 enthalten eine 
Auswahl häufig verwendeter Symbole und ein Beispiel für ein Flussdiagramm. 

Bei der Erläuterung von ARIS in Abschn. 2.5.1.4 haben wir Ereignisgesteuerte 
Prozessketten (EPK) als Modelltyp für die Steuerungssicht angesprochen. Bei diesen 
EPKs handelt es sich um Flussdiagramme aus Sequenzen von Ereignisknoten, Funktions- 
knoten (Operationen) und Konnektoren. Pfeile als Kanten repräsentieren Kontrollflüsse 
zwischen den Symbolen. Funktionen und Ereignisse (mit Ausnahme von Start- und Ende- 
reignis) besitzen genau je eine eingehende und eine ausgehende Kante. Sollen Funktionen 
mehrere Ereignisse erzeugen oder mehrere Ereignisse eine Funktion auslösen, müssen 
Konnektoren wie ein exklusives Oder (XOR) zwischengeschaltet werden. Der Model- 
lierer kann auch ausdrücken, wer eine Funktion mit welcher IT-Unterstützung ausführt 
und welche Daten dabei manipuliert werden. Dazu ordnet er den Funktionsknoten Sym- 
bole für Organisationseinheiten (z. B. Abteilungen, Stellen, Rollen), Informationsobjekte 
(Daten) oder Anwendungssysteme zu. Diese Elemente müssen in den entsprechenden 
Modelltypen spezifiziert sein. Man spricht dann von erweiterten Ereignisgesteuerten 
Prozessketten (eEPK). 


SDetails dazu finden sich in einschlägiger Literatur, z. B. bei [22]. 
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Den Zusammenhang, den eine eEPK als Instrument der Steuerungs- oder Prozesssicht 
mit den Elementen der anderen Sichten und Modelltypen herstellt, haben wir bereits in 
Abschn. 2.5.1.4 kurz angedeutet. Konkret äußert er sich folgendermaßen: 


e Steuerungssicht 

— Ein Ereignis ist ein Zustand, der vor oder nach einer Funktion auftritt. Das Symbol 
für ein Ereignis ist sechseckig. 

— Eine Funktion (Prozess) ist eine Aktion oder Aufgabe, die auf ein Ereignis folgt. 
Funktionen werden durch Rechtecke mit abgerundeten Ecken symbolisiert. 

— Konnektoren dienen zum Aufspalten (Split) oder Vereinigen (Join) des Kontroll- 
flusses. Es stehen die drei Konnektoren UND, ODER und XOR zur Verfügung, die 
jeweils in einem kleinen Kreis mit dem entsprechenden Symbol dargestellt wer- 
den. Die Entscheidung, welcher Pfad nach einem Konnektor verfolgt wird, trifft 
die dem Konnektor vorangehende Funktion. 

e Funktionssicht 

— Die Funktionsknoten in der Steuerungssicht werden mit Knoten aus dem 
Funktionsbaum der Funktionssicht verknüpft — damit wird jeweils die auszu- 
führende Aktivität spezifiziert. 

e Datensicht 

— Informationsobjekte sind Entitäten aus dem Datenmodell, die an Träger wie Doku- 
mente oder sonstige Datenspeicher gebunden sind. Sie stellen und Inputs oder Out- 
puts der Funktion dar, mit der sie durch eine gerichtete Kante verbunden werden. 
Das Symbol für ein Informationsobjekt ist ein Rechteck, der Charakter als Input 
oder Output bestimmt die Pfeilrichtung der Verbindungskante. 
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Abb. 2.18 Erweiterte Ereignisgesteuerte Prozesskette für Kontotransaktion 


e Organisationssicht 
— Organisationseinheiten zeigen an, welche Elemente aus dem für die Organisations- 
sicht modellierten Organigramm die Aktivitäten (Funktionen) im Prozess aus- 
führen. Organisationseinheiten werden durch ungerichtete Kanten mit Funktionen 
verbunden. 


In Abb. 2.18 ist das Flussdiagramm aus Abb. 2.17 in der Notation einer erweiterten 
Ereignisgesteuerten Prozesskette zu sehen. 


2.6.4 Petrinetze 


Einer der ersten und auch am weitest verbreiteten Theorieansätze zur Beschreibung von 
Parallelität sind Petrinetze. 

Petrinetze dienen der logischen Modellierung von Verhalten. Sie betrachten das Ver- 
halten von Systemen, in der Regel von Informationssystemen unter folgenden Aspekten: 


e Auszuführende Aktivitäten 
e Vor- und Nachbedingungen einer Aktivität 
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e Zustände aller Bedingungen (mögliche Ausprägung für jede einzelne Vor- bzw. 
Nachbedingung: Zustand einer Bedingung ist die Verteilung sogenannter Marken als 
Zustandsanzeige auf den Vor- bzw. Nachbereich) 

e Anfangszustand (Anfangsmarkierung) 

e Abläufe (mögliche Folgen von Aktivitäten) 


Ein Petrinetz ist ein Gebilde, das formal und mathematisch präzise beschrieben wird 
als gerichteter Graph mit Knoten, die aus zwei disjunkten Teilmengen bestehen und mit 
Markierungen versehen sind. In der Schreibweise als Quadrupel gilt: Ein Petri Netz ist 
ein Quadrupel: PN = (S, T, K, M) mit 


e s e S: Stellen (oder auch Plätze), zur Beschreibung von Zuständen und/oder 
Bedingungen, Puffer, Speicher oder Lager, im Graph kreisförmig. Sie dienen der 
Ablage von Information bzw. der Markierungen. 

e tc T: Transitionen, beschreiben Zustandsübergänge, Ereignisse, Aktionen oder Tätig- 
keiten und sind im Graph strich-, balken- oder quaderförmig. Ihr Zweck ist die Ver- 
arbeitung von Information. 

e ke kK: Kanten sind ggf. gewichtete (d. h. mit Zahlen versehene) Verbindungen zwi- 
schen Stellen und Transition, im Graph als Pfeile dargestellt. Sie zeigen den Verlauf 
der Transitionen an. 

e me M: Marken (Token), die den aktuellen Zustand des Petrinetzes wiedergeben. 
Jedes Netz hat einen Initialzustand, d. h. es gibt eine Anfangsmarkierung. 


Gemäß obiger Definition gehen Kanten jeweils nur von Stelle zu Transition bzw. Tran- 
sition zu Stelle. Eingabestellen einer Transition t sind Stellen, von denen Kanten zur 
Transition t laufen. Ausgabestellen einer Transition t sind Stellen, zu denen Kanten der 
Transition t führen. 

Eine Transition kann schalten, wenn in jeder Eingabestelle mindestens eine Marke 
(Token) liegt. Schalten heißt, dass aus jeder Eingabestelle der schaltenden Transition ein 
Token abgezogen und jeder Ausgabestelle ein Token hinzugefügt wird. 

Die folgenden Grafiken zeigen ein Petrinetz mit seinen jeweiligen Zuständen nach 
der Durchführung der Schaltoperationen. Im Startzustand in Abb. 2.19 hat nur die Stelle 


Schritt 1 


Anfangsmarkierung 


ann] 


Abb. 2.19 Petrinetz I 
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sl eine Markierung, die Initial- oder Anfangsmarkierung. Die Stelle sl ist die einzige 
Eingangsstelle der Transition tl, die deshalb schalten kann. Die Markierung wird aus sl 
abgezogen und eine Markierung zur einzigen Ausgangsstelle s2 hinzugefügt. Die rechte 
Hälfte des folgenden Bildes zeigt den Zustand nach dem Schalten von tl. 

Die Stelle s2 ist die Eingangsstelle der beiden Transitionen t2 und t3 (vgl. linke 
Seite von Abb. 2.20). Es könnte also die Transition t2 oder t3 schalten, aber nicht beide. 
Welche Transition schaltet ist zufällig. Damit haben wir einen sogenannten nicht- 
deterministischen Zustand. Schaltet t3, wird der Stelle s5 ein Token hinzugefügt und ein 
Endzustand erreicht, da aus s5 keine Kante mehr herausführt. Schaltet die Transition t2, 
so wird den Stellen s3 und s4, die Ausgangsstellen von t2 sind, jeweils ein Token hinzu- 
gefügt. Den entsprechenden Zustand zeigt die rechte Hälfte von Abb. 2.20. 

Nun kann entweder die Transition t4 oder t5 schalten. Hier könnte man folgern, dass 
diese beiden Transitionen gleichzeitig schalten. Dies ist aber in Petrinetzen nicht erlaubt. 
Zu einem Zeitpunkt darf nur genau eine Transition schalten. Es ist also keine echte 
Parallelität möglich. Es ist aber willkürlich, ob nun zuerst t4 oder t5 schaltet. In unserem 
Beispiel schaltet erst t4 und dann t5. Wenn beide Transitionen geschaltet haben, ist wie- 
der ein Endzustand erreicht. Abb. 2.21 zeigt die entsprechenden Netzzustände. 

Petrinetzmodelle erlauben die Analyse und Simulation von dynamischen Systemen 
mit nebenläufigen und nicht-deterministischen Vorgängen. 

Bei der vorgestellten Art der Petrinetze handelt es sich um die Grundversion. Mit ihr 
lassen sich bestimmte Sachverhalte nicht beschreiben. Beispielsweise ist es nicht mög- 
lich, Prioritäten für Transitionen zu vergeben, weshalb z. B. die Rechts-vor-links-Regel 
an Verkehrskreuzungen nicht modelliert werden kann. 

Um solche Defizite zu beheben wurden Erweiterungen eingeführt, mit denen man dem 
Modell weitere Aspekte der Wirklichkeit hinzuzufügen bzw. bestimmte Sachverhalte 


Schritt 2.1 


Abb. 2.20 Petrinetz II 


Schritt 3.1 


Endemarkierung 


Abb. 2.21 Petrinetz III 
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kompakter zu beschreiben kann. Beispiele sind mehrwertige, bunte oder mit Prioritäten 
versehene Petrinetze®. 


2.6.5 Calculus of Communicating Systems 


Der Calculus of Communicating Systems (CCS) wurde von Robin Milner im Jahr 
1980 [24] publiziert. Dieser Kalkül erlaubt die formale Modellierung von parallelen 
kommunizierenden Systemen. Damit können vernetzte Systeme mit einer statischen 
Topologie beschrieben werden. Mit CCS können Eigenschaften von Programmen wie 
Verklemmungen, Verhaltensgleichheit etc. formal untersucht werden. CCS erlaubt die 
Beschreibung von folgender Aspekte: 


e Kommunikation zwischen Akteuren über Kanäle 

e Interaktion mit der Umgebung, d. h. Reaktivität 

e Parallele Komposition 

e Verbergen von Aktionen gegenüber der Umwelt (Information Hiding) 
e Nicht-deterministische Verzweigungen 


Der Ablauf eines Prozesses wird als Baum beschrieben, d.h. es gibt eine Wurzel, die 
den Anfangszustand darstellt und von der die einzelnen Äste ausgehen. Jeder der Äste 
ist markiert. Diese Markierungen repräsentieren die Aktionen, die ausgeführt werden, 
um von einem Zustand zum Folgezustand zu gelangen. Es wird zwischen beobachtbaren 
und nicht beobachtbaren Aktionen unterschieden. Nicht beobachtbare Aktionen können 
innerhalb eines Prozesses jederzeit ausgeführt werden, ohne dass dies Auswirkungen auf 
andere Prozesse hat. Prozesse haben keine gemeinsamen Variablen. 

Um das Verhalten eines Prozesses zu beschreiben werden rekursive Ausdrücke ver- 
wendet. Innerhalb von Verhaltensausdrücken können Variablen verwendet werden, um 
andere Verhaltensausdrücke zu referenzieren.Die Verhaltensausdrücke werden gemäß 
folgender Syntax beschrieben, bei der Großbuchstaben Prozessnamen und Kleinbuch- 
staben Aktionen bezeichnen. 


e Leerer Prozess: 
Ø 
e Aktion 
Der Prozess a.P1 führt die Aktion a aus und verhält sich dann wie P1 
e Prozessname 
Mit dem Ausdruck A: =P1 erhält der Prozess Pl den Namen A. Da rekursive Defini- 
tionen erlaubt sind kann in dem Ausdruck P1 der Name A wieder enthalten sein. 


Einzelheiten zu solchen Erweiterungen finden sich in der verfügbaren Literatur, wie z. B. bei [23]. 
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e Auswahl 
Der Prozess P1+P2 kann entweder mit dem Prozess P1 oder dem Prozess P2 fort- 
gesetzt werden. 

e Parallelkomposition 
P1IP2 bedeutet, dass die Prozesse Pl und P2 parallel ausgeführt werden 

e Umbenennung 
P1[b/a] beschreibt den Prozess P1, in dem alle Aktionen mit der Bezeichnung a in b 
umbenannt werden. 

e Restriktion 
P1\a bezeichnet den Prozess P1 ohne die Aktion a 


Zueinander passende Ein- und Ausgabeaktionen in zwei unterschiedlichen Prozessen 
können sich synchronisieren und zu einer internen Aktion t werden. Im Allgemeinen 
wird die Koaktion zu einer Aktion mit einem Querstrich über dem Aktionsnamen 
gekennzeichnet. Diese komplementären Aktionen sind die Sende- und Empfangs- 
aktionen. Abb. 2.22 zeigt beispielhaft die Interaktion zwischen zwei Prozessen. 

Das folgende Beispiel (siehe Abb. 2.23) zeigt, wie mit CCS ein einfacher Urlaubs- 
antragsprozess beschrieben werden kann. 

Im Prozess Mitarbeiter wird die Sendeaktion Urlaubsantrag ausgeführt (Aktions- 
name mit Überstrich). Danach wird auf die Nachrichten ‚abgelehnt‘ oder ‚genehmigt‘ 
gewartet. Der Manager empfängt die Nachricht Urlaubsantrag, die er entweder mit der 
Nachricht ‚genehmigt‘ oder ‚abgelehnt‘ beantwortet. Falls er die Nachricht ‚genehmigt‘ 
sendet, wird danach auch noch die Nachricht ‚genehmigter Urlaubsantrag‘ gesendet. 
Diese Nachricht empfängt die Reisestelle. Der Austausch von Nachrichten erfolgt in 
CCS asynchron, d. h. ein Sender wartet so lange, bis der Empfänger die dazugehörige 
Empfangsaktion ausführt. 


a a.P | aQ _ e Die Prozesse a.P und ā.Q werden 
ea N e Parallel ausgeführt. 
e Ausgehend von a.P|ä.Q sind drei 
| a.P lQ ° Übergänge (Transistionen) möglich. 
| 


e Findet eine Synchronisation zwischen a und a 
a a e Statt so entsteht die von außen unsichtbare 
PIQ z 
e Transition 


Abb. 2.22 Prozessinteraktion mit CCS 


Mitarbeiter := Urlaubsantrag.(abgelehnt + genehmigt) . NIL 


Manager := Urlaubsantrag. (abgelehnt + genehmigt.genehmigterUrlaubsantrag).NIL 


Reisestelle:= genehmigterUrlaubsantrag.NIL 


Urlaubsantragsprozess := Mitarbeiter | Manager | Reisestelle 


Abb. 2.23 Beispielprozess in CCS 
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Zu der ausgeführten informellen Interpretation gibt es auch formale Ableitungsregeln. 
Damit werden Prozessdefinitionen zugänglich für formale Untersuchungen. 


2.6.6 n-Kalkül 


CCS erlaubt nur statische Prozessstrukturen. Kommunikationsbeziehungen können nicht 
dynamisch verändert werden. Der n-Kalkül [25], ebenfalls von Robin Milner entwickelt, 
erlaubt die Darstellung von Prozessen mit wechselnden Strukturen. Es sind beliebige 
Verbindungen zwischen Komponenten darstellbar und diese Verknüpfungen können 
sich auch ändern bzw. neue können entstehen. Damit ist der n-Kalkül eine Erweiterung 
des CCS um Nebenläufigkeit. Die Notation im n-Kalkül orientiert sich weitgehend an 
der CCS-Notation. Das folgende Beispiel erläutert die Modellierungsmöglichkeiten des 
n-Kalküls (vgl. Abb. 2.24). 

Der Agent (Prozess) P möchte den Wert 7 an Q über einen Link a senden. Allerdings 
soll der Wert indirekt über einen weiteren Agenten R übertragen werden. 

Die einzelnen Schritte bei der Ausführung des Systems O sind in Abb. 2.25 sichtbar. 

Die Prozesse P, R und Q werden parallel ausgeführt. Prozess P sendet über den Kanal 
b den Namen a und dann den Namen 7. Der Prozess P erhält über den Kanal b die bei- 
den Namen. Dies bedeutet, alle x werden durch a ersetzt und alle z durch 7. In Abb. 2.25 
ist dies das Ergebnis nach Schritt 2. Nun kann über den Kanal a der Name 7 gesendet 
werden, der vom Prozess Q dann angenommen wird. Damit wurde der Wert 7 über den 
Prozess R an den Prozess Q gesendet. Die Abb. 2.26 zeigt, wie durch den Ablauf des 
Systems O seine Struktur geändert wird. 

Da der Kanalname a von P nach R gesendet wird, sind nach der Annahme der Nach- 
richt die Prozesse R und Q über den Kanal a verknüpft. Damit wird deutlich, dass der 
n-Kalkül im Gegensatz zu CCS die Modellierung von Strukturänderungen zulässt. 


e P:= ba. b7.P' Prozess P sendet über den Kanal b den Wert a 
und nachfolgend den Wert 7 und verhält sich dann 
wie P’. 

e R:=b(x).b(z).Xz.0 Prozess R empfängt über den Kanal b jeglichen 
Wert. Dies bedeutet in R wird x und z durch die 
empfangenen Werte ersetzt. 

. Q:=alx).Q Prozess Q empfängt über den Kanal a einen 
beliebigen Wert für x. Der empfangene Wert wird 
überall dort eingesetzt wo sich x befindet. 


e O:=PIRIQ Gesamtsystem O 


Abb. 2.24 Prozessbeschreibung mit n-Kalkül 
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Abb. 2.25 Schritte bei der PIR|Q 
Ausführung des Systems O Schritt 1 J L 


ba. b7.P’ | b(x).b(z)xz.0 | a(x).Q‘ 


Br 
Schritt 2 J 


P’ | 37.0 | a(x).Q‘ 
Schritt 3 


Abb. 2.26 Strukturänderung 


2.6.7 Communicating Sequential Processes 


Communicating Sequential Processes (CSP) ist eine Methodik zur Beschreibung von 
Interaktion zwischen kommunizierenden Prozessen. Die Idee hat Tony Hoare erstmals 
1978 als imperative Sprache vorgestellt [26], dann zu einer formalen Algebra ausgebaut 
und 1985 mit der Veröffentlichung des Buchs mit dem Titel Communicating Sequential 
Processes berühmt gemacht [27]. 

In CSP ist wie in CCS die Anzahl der Prozesse statisch. Sie kann während der Lauf- 
zeit nicht geändert werden und zwischen Prozessen gibt es keine gemeinsamen Variab- 
len. Stattdessen ‚kennen‘ sich die Prozesse und verständigen sich untereinander durch 
das Senden und Empfangen von Nachrichten. Zum Senden führt der Sendeprozess P das 
Ausgabekommando. 

Q ! (expr) 

und der Empfängerprozess Q das Eingabekommando 

P ? (vars) 

aus. Ausgabe- und Eingabekommandos heißen korrespondierend, falls die Folge von 
Ausdrücken (expr) und die Folge von Variablen (vars) in der Anzahl und komponenten- 
weise vom Typ übereinstimmen. Analog CCS und dem n-Kalkül basiert CSP auf einem 
ungepufferten Nachrichtenaustausch, bei dem der Sende- und der Empfangsprozess 
explizit genannt werden müssen. 

Mit Q ! () und P ? () wird eine Nachricht ohne Inhalt gesendet. Solche Nachrichten 
werden als Signale bezeichnet und dienen einzig und allein der Synchronisation von 
Prozessen. Werden unterschiedliche Signale benötigt, so wird die Unterscheidung durch 
Typbezeichner der Form Q ! (Signall) und P ? (Signall) ausgedrückt. 
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Neben dem oben beschriebenen unbedingten Nachrichtenaustausch gibt es die 
Empfangsanweisung innerhalb eines sogenannten Guarded Commands (Bewachte 
Anweisung). Eine bewachte Anweisung wird nur ausgeführt, wenn die vorangestellte 
Bool’sche Bedingung wahr ist. So wird der Formelsatz. 


x > y; Plz) -— >x :=x+ty; y:=Z 


nur ausgeführt, wenn x größer als y ist. Dann wird die Nachricht von P entgegen- 
genommen, falls P bereit ist, die Nachricht zu senden. 

Um auf Nachrichten von unterschiedlichen Sendern warten zu können, werden meh- 
rere Guarded Commands zu einer Alternativanweisung zusammengeschlossen. 


[x > y; PX(Z) — > x :=x + y; y:= z||x <y; Q?lX(z)— > y:= x + y; y := z] 


Im Fall x>Y wird die Nachricht P?(z) erwartet, im Fall x<y die Nachricht Q?(z). Alter- 
nativanweisungen können auch wiederholt ausgeführt werden. Syntaktisch wird dies 
durch einen der Alternativanweisung vorangestellten * ausgedrückt. Die Anweisung. 


*[x > y; P%Xz) -> x := x +y; y:=z||x<y; QUz) -> y:=x + y; y >= z] 


wird solange ausgeführt, bis keine der Bedingungen mehr wahr ist — dann wird die 
Wiederholung beendet. 

Die Konzepte bezüglich der Nebenläufigkeit von CSP dienen als Gestaltungsgrund- 
lage der Programmiersprache Go. 


2.6.8 Abstract State Machines 


Eine abstrakte Zustandsmaschine (Abstract State Machine (ASM)) ist in der Informatik 
ein Modell zur formalen, operationellen Beschreibung von Algorithmen. Die Zustände 
einer abstrakten Zustandsmaschine sind allgemeine mathematische Strukturen. Der 
Erfinder des Modells ist Yuri Gurevich. Egon Börger hat die ASM für die praktische 
Anwendung weiterentwickelt [28]. 

Abstract State Machines (ASM) sind endliche Mengen von Transitionsregeln der 
Form. 

If condition then action 

mit denen die Zustände einer ASM geändert werden. Condition ist dabei ein 
beliebiger logischer Ausdruck und Action eine beliebige Handlung. In der Regel ist 
Action eine Wertzuweisung der Form f(tl,....... tn) :=s. Die Bedeutung der Regel 
besteht darin, im gegenwärtigen Zustand die angegebene Regel auszuführen, wenn die 
angegebene Bedingung in diesem Zustand erfüllt ist. ASM-Zustände werden allgemein 
als beliebige Mengen beliebiger Elemente mit beliebigen darauf definierten Funktionen 
(Operationen) und Prädikaten definiert. Im Fall von Geschäftsobjekten sind die Ele- 
mente Platzhalter für Werte beliebigen Typs und Operationen wie Erzeugen, Duplizieren, 
Löschen oder algebraische Manipulationen von Objekten. 
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Ein Berechnungsschritt einer ASM in einem bestimmten Zustand bedeutet, dass alle 
Actions, für die die Bedingung (Condition) wahr ist, gleichzeitig ausgeführt werden. 
Durch die simultane Ausführung kann von irrelevanten Reihenfolgen abstrahiert werden. 

Mehrere ASMs können gleichzeitig ablaufen und über sogenannte Controlled bzw. 
Monitored Functions verknüpft werden. Eine gegebene ASM M kann Controlled Functions 
aktualisieren, sie kann aber nicht von anderen ASM aus der Umgebung von M verändert 
werden. Monitored Functions einer gegebenen ASM M können nur durch deren Umgebung 
aktualisiert werden. Durch die paarweise Verwendung von Controlled and Monitored Func- 
tions kann ein Netzwerk paralleler sich koordinierender ASMs aufgebaut werden. 


2.6.9 Objektorientierte Modelle 


Die bisher betrachteten Modelle der Informatik legen den Schwerpunkt entweder auf 
Daten oder Funktionen. Die Darstellung von Daten in einem ERM und Funktionen in 
einem Flussdiagramm ergänzen sich nur in entkoppelten Darstellungen — die Unter- 
scheidung in Daten- und Funktionssicht bei ARIS macht dies deutlich. Die objekt- 
orientierte Modellbildung reduziert diese isolierten Sachverhalte nicht mehr auf ihre 
Einzelteile, sondern betrachtet sie als integriertes Ganzes, bei dem die einzelnen Kompo- 
nenten miteinander verbunden und voneinander abhängig sind. 

Unter einem objektorientierten Modell versteht man eine Sichtweise auf ein komple- 
xes System, bei der dieses durch das Zusammenspiel von Objekten beschrieben wird. 
Durch diese Art der Modellbildung soll die Komplexität der Beschreibung für Sachver- 
halte, die in Software abzubilden sind, reduziert werden. Die Objektorientierung sieht 
die in der realen Welt vorkommenden Entitäten als Objekte. Ein Telefon ist ebenso ein 
Objekt, wie ein Fahrrad, ein Mensch oder ein Mitarbeiter. Solche Objekte setzen sich 
wiederum aus anderen Objekten zusammen wie z.B. Schrauben, Stangen, Armen, 
Füßen, Kopf o. Ä. Die Objekte werden, wie in der Modellbildung üblich, auf ihre in der 
jeweiligen Situation bedeutsamen Eigenschaften reduziert. So wird z. B. ein Mitarbeiter 
in einem Lohnabrechnungssystem auf Name, Adresse, Mitarbeiternummer, vereinbartes 
Einkommen, Steuerklasse usw. reduziert. 

Die in einem Modell berücksichtigten Objekte werden nicht einzeln konzipiert. Für 
gleichartige Objekte wird ein grober Bauplan mit gleichartigen Eigenschaften erstellt. 
Beispielsweise modelliert man für eine Bibliotheksanwendung die Eigenschaften von 
Büchern, die für allen Büchern identisch sind. Solche allgemeinen Beschreibungen von 
Objekten werden in der Objektorientierung Klassen genannt. Mit diesen Klassen werden 
dann innerhalb des Modells die benötigten konkreten Objekte erzeugt (Instanzen). 

Die Abbildung der Wirklichkeit in ein Modell erfolgt also zweistufig. Zuerst 
werden gleichartige Objekte der Wirklichkeit identifiziert und jeweils als Klasse 
beschrieben. Die einzelnen Objekte werden dann als sogenannte Instanzen einer Klasse 
erzeugt. Eine Klasse beschreibt somit die Struktur einer Menge gleichartiger Objekte. 
Abb. 2.27 zeigt eine Klasse-Objekt Beziehung, nach der das Buch „Subjektorientiertes 
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<<Instance of>> 


Buch K------------------4 Subjektorientiertes Prozessmanagement 


Abb. 2.27 Beziehung Klasse-Objekt 


Prozessmanagement“ eine Instanz der Klasse Buch ist. Die verwendete Notation ent- 
stammt der Unified Modeling Language (UML). UML ist eine von der Object Manage- 
ment Group standardisierte Sprache zur Beschreibung objektorientierter Modelle. 

Die Eigenschaften einer Klasse sind 


e ihre Bestandteile und die in ihnen enthaltenen Daten und Informationen, auch Attri- 
bute genannt, 

e die auf den Bestandteilen definierten Operationen und ihre Parameter (Methoden), mit 
denen ein Objekt manipuliert bzw. dessen Zustand abgefragt werden kann und 

e Bedingungen, Voraussetzungen und Regeln, die die Objekte erfüllen müssen 
(Zusicherungen). 


Abb. 2.28 zeigt ein Beispiel für die Beschreibung der Klasse Buch. Diese Klasse hat fünf 
Attribute. Das Attribut Seitenzahl hat eine Zusicherung, die besagt, dass die Seitenzahl 
positiv sein muss. Die Klasse erlaubt den Zugriff und die Manipulation ihrer Daten mit 
sechs Methoden. So können der Titel, die Autoren, die Seitenzahl, der Verlag und der 
Inhalt gesetzt werden (Set). Mit der Operation (Methode) AnzeigenSeite(Seite) kann der 
Inhalt der angegebenen Seite aus dem Buch „ausgelesen“ werden. 

Ausgehend von einer solchen Klassendefinition können nun Objekte instanziiert wer- 
den. Mithilfe der Operationen können dann für jede dieser Instanzen die jeweiligen Attri- 
bute entsprechend gesetzt werden. Ein objektorientiertes Modell beschreibt neben den 
Definitionen der Klassen und der zugehörigen Objekte auch die Beziehungen der Klas- 
sen zueinander. Die Arten von Beziehungen sind: 


e Vererbung 
Eigenschaften können von einer Klasse zur nächsten weitergegeben werden. Man 
spricht dann von Vererbung. Die Klasse, die vererbt, heißt Oberklasse, und die Klasse, 
die erbt, Unterklasse. So ist eine Klasse Notizbuch Unterklasse der Klasse Buch. Der 
Klasse Notizbuch wird noch die Methode „Seiteneintrag (Seite, Inhalt)“ hinzugefügt. 
Damit kann auf der angegebenen Seite ein Text eingegeben werden; Ansonsten erbt 
die Unterklasse Buch alle Attribute und Methoden von der Klasse Buch. Abb. 2.29 
zeigt die Vererbungsbeziehung zwischen Buch und Notizbuch. Der Dreieckspfeil 
zeigt von der Unterklasse zur Oberklasse. 

e Assoziationen 
Eine Assoziation ist eine Beziehung zwischen verschiedenen Objekten einer oder 
mehrerer Klassen. Dargestellt werden Assoziationen als einfache Linie zwischen zwei 
Klassen. Die Linie kann mit einem Namen (Bezeichnung) und Anzahlangaben ver- 
sehen werden. Auch die assoziierten Klassen können Namen bezüglich der Beziehung 
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Abb. 2.28 Beschreibung der 
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Abb. 2.29 Vererbung von 
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Abb. 2.30 Assoziationen Firma Person 


zwischen Objekten Arbeitgeber Arbeitnehmer 


erhalten. Abb. 2.30 illustriert ein Beispiel für eine Assoziation. Eine Person (Arbeit- 
nehmer) kann bei keiner oder einer Firma (Arbeitgeber) beschäftigt sein und eine 
Firma kann keine oder mehrere Personen beschäftigen. Assoziationen haben eine 
große Ähnlichkeit mit den Entity-Relationship-Diagrammen. 
e Aggregationen 

Aggregationen sind eine Variante von Assoziationen. Dabei handelt es sich eben- 
falls um eine Beziehung zwischen zwei Klassen, jedoch mit der Besonderheit, dass 
die zwei Klassen zueinander in Beziehung stehen wie ein Teil zu einem Ganzen. 
Eine Aggregation setzt sich zusammen aus einer Menge von Einzelteilen. Abb. 2.31 
zeigt ein Aggregationsbeispiel, bei dem ein Unternehmen aus Abteilungen, und eine 
Abteilung aus Mitarbeitern besteht. 
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7 1__ Bestehtaus> 1..* 3 1 Besteht aus> 1,,* 
Abteilung t Person 


Abb. 2.31 Mehrstufige Aggregation 


1__ Besteht aus> 1..* 1 hat> Ia” 
Firma k > Abteilung t Person 


Abb. 2.32 Komposition 


1 Seiteneintrag(Seite, Inhalt) -> 1 
Person Notizbuch 


Abb. 2.33 Nachricht zwischen Objekten 


e Komposition 
Eine besondere Form der Aggregation ist die Komposition. Hier hängt das Ganze 
von der Existenz seiner Einzelteile ab. In Abb. 2.32 ist eine Änderung an der obigen 
Aggregation zu sehen. Eine Abteilung besteht nicht mehr, wenn ihr niemand angehört. 
e Objekte kommunizieren miteinander, d. h. ein Objekt sendet Nachrichten an ein ande- 
res Objekt. Die Nachrichten stoßen dann die zugehörigen Operationen an. Ein Objekt 
versteht also nur die Nachrichten, zu denen es auch die zugehörigen Operationen ent- 
hält. Abb. 2.33 zeigt die Kommunikation einer Person mit dem Notizbuch zum Ein- 
tragen einer neuen Notiz. 
Die beschriebenen Konstrukte bilden den Nukleus des objektorientierten 
Modellierungsansatzes. Darüber hinaus existieren zahlreiche Erweiterungen zur 
Abbildung bestimmter Sachverhalte wie die sogenannten Behälterklassen”. 


2.6.10 Agenten-/Aktoren-orientierte Modelle 


Bislang gibt es keine standardisierte und allgemein akzeptierte Definition des Agenten- 
konzepts. Der Begriff wird abhängig von der Anwendungsdomäne im Detail unter- 
schiedlich definiert [30]. All diesen Definitionen ist aber gemeinsam, dass ein Agent eine 
abgrenzbare Einheit ist, die in der Lage ist, die ihr vorgegebenen Aufgaben flexibel, inter- 
aktiv und autonom zu verfolgen. Oft wird der Begriff Aktor als synonym für den Begriff 
Agent benutzt. So definieren Lankhorst et al. [31] einen Business Actor als ‚... an entity 


"Weiterführende Informationen finden sich beispielsweise bei [29]. 
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that is capable of performing behavior“. Multiagentensysteme bestehen aus mehreren 
Agenten, die synchron oder asynchron Nachrichten austauschen. Multiagentensysteme 
können die Strukturen von Softwaresystemen abbilden oder auch der Modellbildung 
sozialer Systeme dienen. Je nach Anwendungssituation kann dann zwischen Software- 
agenten und menschlichen Agenten unterschieden werden. 

In gewisser Weise können die Prozesse in CCS, im n-Kalkül und in CSP als Multi- 
agentensysteme betrachtet werden. Der Begriff Prozess wird dort analog zu den 
Begriffen Agent und Aktor verwendet. 

Ein agentenorientiertes Modell beinhaltet also die Agenten, die Kommunikations- 
pfade und die Nachrichten, die ausgetauscht werden.® 


2.7 Fazit: Modelle für Geschäftsprozesse 


Geschäftsprozessmodelle bilden den Wirklichkeitsausschnitt der Geschäftsprozesse ab. 
Das subjektive Verständnis des Geschäftsprozessbegriffs beeinflusst, welche Prozess- 
aspekte als wesentlich erachtet werden und deshalb in den Modellen im Vordergrund 
stehen. Hier schlagen sich Absichten und Interessen des Modellerstellers nieder. Konse- 
quenz sind zahlreiche Auslegungen des Geschäftsprozessbegriffs, von denen jede weder 
richtig noch falsch ist, sondern lediglich andere Betrachtungsschwerpunkte setzt.Als 
Beispiele dafür können folgende Definitionen des Terminus Geschäftsprozess gelten: 


1. „Folge von Wertschöpfungsaktivitäten (Wertschöpfung) mit einem oder mehreren 
Inputs und einem Kundennutzen stiftenden Output“ [33]. 

2. „Ein Prozess ist die inhaltlich abgeschlossene, zeitliche und sachlogische Folge von 
Aktivitäten, die zur Bearbeitung eines betriebswirtschaftlich relevanten Objekts not- 
wendig sind.“ [34]. 


Beide Definitionen stellen auf die erforderlichen Aktivitäten und deren Folgen ab. Das 
erste Beispiel erwähnt zusätzlich den Input und den Output mit dem Kundennutzen, 
während in der zweiten Definition stattdessen die Bearbeitung der Geschäftsobjekte ein- 
bezogen wird. 

Handelnde und benötigte Ressourcen fehlen dagegen in beiden Begriffsfassungen. Sie 
betrachten nicht, durch wen und womit die Aktivitäten ausgeführt werden. Es gibt keinen 
Bezug zur Organisation, in die ein Geschäftsprozess eingebettet ist, sowie dazu, welche 
IT-Anwendungen oder sonstige Ressourcen eingesetzt werden, um ihn auszuführen. Wir 


$Eine Sammlung von agentenorientierten Modellierungssprachen und den dazugehörigen Vor- 
gehensweisen findet sich in [32]. 
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folgen deshalb in Anlehnung an Gerhard Schewe einem Begriffsverständnis, das auch 
diese fehlenden Aspekte berücksichtigt [33]: 


. Ein Prozess ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), 

. die von Handelnden (Menschen, Systeme als Aufgabenträger) 

. in sachlogischer und zeitlicher Reihenfolge 

. mit Hilfsmitteln (Sachmittel, Information) 

. zur Bearbeitung eines Geschäftsobjekts ausgeführt werden, 

. um ein Kundenbedürfnis zu befriedigen (und damit zur Wertschöpfung beizutragen), 
. und einen definierten Anfang und Input 

. sowie ein definiertes Ende und Ergebnis aufweisen. 


oa uw 


Wie bereits in Abschn. 1.3 ausgeführt, formen wir die Bestandteile etwas um und grup- 
pieren sie wie folgt: 


9. Prozessstrategie: Ein Prozess hat 
a) einen definierten Anfang und Input (Startereignis), 
b) und weist ein definiertes Ende mit einem Ergebnis auf, 
c) das zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung) 
beiträgt 
10. Prozesslogik: Ein Prozess 
a) ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), 
b) die nach dem Startereignis von Handelnden 
c) in sachlogischer und zeitlicher Reihenfolge 
d) zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um 
e) das gewünschte Ergebnis zu erzeugen. 
11. Prozessrealisierung: Ein Prozess wird realisiert 
a) mit Menschen und/oder Maschinen, die Aufgaben der jeweiligen Handelnden 
übernehmen, und diese 
b) mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen. 


Mit diesem Verständnis von Geschäftsprozessen wird der Bezug der in diesem Kapi- 
tel beschriebenen Modelle aus unterschiedlichen Domänen zum Geschäftsprozess- 
management deutlich. Abb. 2.34 zeigt entsprechend den integrativen Charakter der 
Geschäftsprozessmodelle.Die Modelle von Habermas und Luhmann befassen sich mit 
Aspekten der gesellschaftlichen Systeme und Organisationen. Sie beschreiben welche 
Komponenten und Beziehungen eine Organisation ausmachen und wie Menschen darin 
positioniert sind. Komplexe Organisationen können beispielsweise anhand betrieblicher 
Funktionen, Leistungsspektrum, geografischer Aspekten oder Kombinationen davon in 
Teilorganisationen strukturiert werden. Das Ergebnis ist das Organigramm. 
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Abb. 2.34 Integration verschiedener Modelle durch Geschäftsprozessmodelle 


Geschäftsmodelle betrachten unter anderem die Aspekte Kunden, Lieferanten, Partner 
und Wertschöpfung und blicken damit zunächst auf die externen Leistungsbeziehungen. 
Insbesondere mit Wertversprechen (Produkte und Services), Aktivitäten und Ressourcen 
stellen sie aber auch die Verbindung zur stärker nach innen gerichteten Unternehmens- 
architektur her. In dieser sind auf der fachlichen Ebene die Aufbauorganisation mit den 
personellen Ressourcen, die Prozesse und die logischen Geschäftsobjekte modelliert. 
Die Verknüpfung mit der technischen Schicht der Unternehmensarchitektur führt zu den 
Modellen aus der Informatik. Diese beschreiben etwa Datenstrukturen, Kontrollflüsse 
und Algorithmen für Programme sowie die Gestalt und das Zusammenwirken weiterer 
informations- und kommunikationstechnischer Komponenten, die für die Ausführung 
gewünschter Aktionen im Rahmen der Prozessunterstützung und -automatisierung nötig 
sind. 
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Modellierungssprachen 


Mithilfe von Modellierungssprachen wird festgelegt, mit welchen Konzepten ein Aus- 
schnitt der menschlich wahrgenommenen Realität beschrieben werden kann und wie 
diese zueinander in Beziehung gesetzt werden können. Modellierungssprachen stellen 
also das Vokabular und die Grammatik zur Verfügung, die benötigt werden, um Sach- 
verhalte der menschlich wahrgenommenen Realität in Modellen abbilden zu können. Sie 
werden in der Folge strukturiert betrachtet. 

Die Verwendung einer bestimmten Modellierungssprache schafft einen definier- 
ten Ausgangspunkt für die Modellbildung, auf den sich alle beteiligten Akteure — seien 
sie aktiv an der Erstellung oder passiv als Konsumenten beteiligt — beziehen kön- 
nen. Akteure können hier einerseits Personen sein, denen durch die Modellierungs- 
sprache ein gemeinsames, definiertes Vokabular zur Verfügung gestellt wird, um sich 
ein gemeinsames Verständnis über den Modellgegenstand zu bilden. Andererseits kön- 
nen Akteure auch Computersysteme sein, denen durch eine in der Modellierungssprache 
exakt spezifizierte Semantik von Modellelementen die Gelegenheit geboten wird, 
Modelle automationsgestützt weiter zu verarbeiten, um sie etwa als Grundlage für Work- 
flow-Unterstützung einzusetzen. 

Von der Wahl der Modellierungssprache hängt also ab, was in einem Modell 
überhaupt abgebildet werden kann, und was nicht sichtbar werden kann, weil die 
Modellierungssprache keine Konzepte dafür anbietet. Die Wahl der Modellierungs- 
sprache beeinflusst auch die Verwendbarkeit des Modells für unterschiedliche Ziel- 
gruppen: Während manche Modellierungssprachen eher zur Unterstützung der 
Kommunikation menschlicher Akteure konzipiert wurden, und dem entsprechend 
manchmal auch eine „vage“ Abbildung von Sachverhalten ermöglichen, gibt es andere 
Modellierungssprachen, die für eine exakte Spezifikation von Sachverhalten konzipiert 
sind und deren Anwendungsfeld eher in der Aufbereitung von Modellen für die Ver- 
wendung in IT-Systemen liegt. Die Wahl einer Modellierungssprache ist also abhängig 
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von der jeweiligen Zielsetzung der Modellbildung und damit ein wesentlicher Schritt hin 
zu einer erfolgreichen Unterstützung jener Aktivitäten, in denen die Modellierung ein- 
gebettet ist. 

Im vorliegenden Abschnitt wollen wir die Grundlage für die sach- und personen- 
gerechte Auswahl einer passenden Modellierungssprache schaffen und stellen dazu 
unterschiedliche Sprachen mit deren jeweiligen Zielsetzungen und Sprachelementen 
vor. Der Fokus liegt hier auf der Abbildung von Geschäftsprozessen, weshalb alle im 
der Folge behandelten Sprachen im weiteren Sinne die Abbildung von Verhalten von 
Akteuren in Organisationen ermöglichen. Im Verständnis darüber, was nun ein Akteur 
sein kann und wie dieses Verhalten beschrieben wird, unterscheiden sich die Sprachen 
fundamental. Dies ist deren Entstehungsgeschichte und den jeweiligen Zielsetzungen 
geschuldet. Die Anordnung der einzelnen Ansätze folgt einer historischen Perspek- 
tive, um die Zusammenhänge zwischen den Sprachen und deren Entstehung deutlich 
hervortreten zu lassen. Für jede der Sprachen betrachten wir abschließend, wie sich 
diese zur Abbildung von Prozessen entsprechend unserer Definition eignen und wo ihre 
Abbildungsschwerpunkte bzw. Lücken liegen'. 


3.1 Überblick 


Flowcharts sind die älteste bis heute gebräuchliche Repräsentationsform von Model- 
len des Kontrollflusses in einem Computerprogramm. Aufgrund der Generalität ihrer 
Sprachelemente werden sie auch für Zwecke der Modellierung von Abläufen in Orga- 
nisationen eingesetzt und sind hier deshalb als Einstieg in die grafische Prozess- 
modellierung zu betrachten. Sie weisen das Konzept der Verzweigung im Kontrollfluss 
zur Abbildung von alternativen Abläufen auf. 


eEPKs („erweiterte Ereignisgesteuerte Prozessketten‘“) stellten in Europa lange Zeit einen 
de-facto Industriestandard für die Geschäftsprozessmodellierung dar. Sie umfassen neben 
der Modellierung von Abläufen auch Elemente, mit denen Verantwortlichkeiten, Daten 
oder Leistungen modelliert werden können und sorgen damit dafür, dass Geschäfts- 
prozesse gemeinsam mit ihrem organisationalen Kontext in Modellen abgebildet werden 
können. Darüber hinaus erlauben sie die explizite Modellierung von parallelen Aktivitäten 
und gehen damit bezüglich der Abbildung des Arbeitsablaufs über die Ausdrucksstärke 
von Flowcharts hinaus. 


UML Aktivitätsdiagramme sind historisch gesehen eine Weiterentwicklung von Flow- 
charts und stellen heute als Teil der Unified Modeling Language (UML) den de-facto 
Standard zur Abbildung von Kontrollflüssen in Software dar. Auch sie ermöglichen die 


'Die fachliche Grundlage zu diesem Kapitel findet sich in folgenden Quellen; www.iso.org, [1, 2]. 
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Abbildung von parallelen Abläufen. Anhand von Aktivitätsdiagrammen führen wir die 
Strukturierung von Modellen durch Partitionierung und Schachtelung ein und zeigen 
damit, wie Modelle auch anhand von Verantwortlichkeiten und nicht nur ausschließlich 
anhand des Arbeitsablaufs strukturiert werden können. 


BPMN (Business Process Modelling and Notation) ist der heute meist eingesetzte Stan- 
dard zur Abbildung von Geschäftsprozessen. Ausgehend von mehreren unterschiedlichen 
Modellierungssprachen — unter anderem von Aktivitätsdiagrammen — wurde eine Spra- 
che definiert, die explizit zur Abbildung von Geschäftsprozessen geeignet sein sollte und 
mit deren Hilfe Modelle für unterschiedliche Zielsetzungen — von der Kommunikations- 
unterstützung bis hin zur Ausführung in Workflowmanagement-Systemen - erstellt wer- 
den können sollten. Aus Sicht der Sprachkonzeption ist die BPMN vor allem hinsichtlich 
ihrer Möglichkeiten zur kompakten Abbildung von komplexen Abläufen (etwa Aus- 
nahmebehandlungen) interessant. 


S-BPM (Subject-oriented Business Process Modeling) ist ein Modellierungsansatz, der 
die in einem Geschäftsprozess involvierten Akteure und deren Interaktionsverhalten 
ins Zentrum der Modellbildung stellt. Die sich daraus ergebende Modellierungssprache 
zeichnet sich durch einen geringen Umfang von Sprachelementen bei gleichzeitig 
umfassender Ausdrucksstärke zur Abbildung von Geschäftsprozessen aus. Sie wird hier 
einerseits als Vertreterin eines nicht vorrangig ablauforientierten Herangehens an die 
Geschäftsprozessmodellierung vorgestellt und bildet außerdem in der Sprachkonzeption 
eine Alternative zur BPMN und ihrem sehr umfangreichen Satz an Modellierungs- 
elementen. 


3.2 Flowcharts 


Flowcharts (oder deutsch: Flussdiagramme bzw. ursprünglich Programmablaufpläne) 
ermöglichen es, einfache, sequenzielle Prozesse abzubilden. Ein sequenzieller Prozess 
zeichnet sich dadurch aus, dass zu keinem Zeitpunkt mehr als eine Aktivität gleichzeitig 
durchgeführt wird — parallele Abläufe können also nicht abgebildet werden. Erstmals 
beschrieben wurden Flowcharts im Rahmen der industriellen Produktionsplanung in den 
1920er-Jahren. Ende der 1940er-Jahre wurden sie für die Beschreibung von Prozessen 
in der aufkommenden Informationstechnologie adaptiert. Seit Mitte der 1960er-Jahre 
stellen sie eine standardisierte Repräsentationsform für Programmabläufe dar. Bis heute 
sind sie ein Mittel der Wahl, um Abläufe in Computerprogrammen oder auch Prozesse in 
Organisationen darzustellen, solange deren Komplexität die Ausdrucksstärke eines Flow- 
chart nicht übersteigt. 

Die Einschränkung der Ausdrucksstärke von Flowcharts ist deren historischen Ent- 
wicklung geschuldet. Sowohl in der industriellen Produktionsplanung als auch in frü- 
hen Computersystemen war es nicht notwendig, parallele Abläufe abbilden zu können. 
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Durch die eingeschränkten zur Verfügung stehenden Ressourcen (in Computern: nur eine 
CPU bzw. nur ein Prozessorkern) war es schlicht nicht notwendig, Sprachelemente zur 
Abbildung etwa von parallelen Abläufen zur Verfügung zu stellen. 


3.2.1 Notationselemente 


Flowcharts kommen heute in vielen unterschiedlichen Varianten vor, die sich vor allem 
in der verwendeten Notation (d.h. der graphischen Darstellung) unterscheiden. Die 
Semantik der Sprachelemente ist aber allen gemein: Grundsätzlich wird eine beliebige 
Anzahl von Operationen (also Aktivitäten, dargestellt als Rechtecke) definiert. Diese 
werden mittels gerichteten Verbindungen (dargestellt als Pfeile) in die Reihenfolge 
gebracht, in der sie ausgeführt werden sollen. Terminierungselemente (dargestellt als 
abgerundete Rechtecke) kennzeichnen den Beginn und das Ende eines Prozesses (siehe 
Abb. 3.1). 

Ein wesentliches Mittel der Beschreibung von Prozessen — sowohl in einem 
Computerprogramm als auch in Organisationen — stellt die Abbildung von alternativen 
Operationen dar. Die Auswahl einer Alternative ist üblicherweise abhängig von einer 
Bedingung, die geprüft werden kann — in einem Computerprogramm könnte dies das 
Überschreiten eines Grenzwertes in einer Variablen sein, in einer Organisation etwa das 
Vorhandensein eines bestimmten Dokuments oder die Entscheidung einer für die Aus- 
führung des Ablaufs verantwortlichen Person. Alternativen werden in Flowcharts durch 
Verzweigungen abgebildet (dargestellt als Rauten), die durch einen eingehenden Pfeil 
von der vorhergehenden Operation und mit zwei ausgehenden Pfeilen mit den alternativ 
ausgeführten nachfolgenden Operationen verbunden sind. 

Die Einschränkung auf genau zwei (und nicht mehrere) nachfolgende Operationen 
ist ebenfalls der Herkunft von Flowcharts aus der Abbildung von Computerprogrammen 
geschuldet, da diese eine Bedingung üblicherweise ausschließlich binär (d. h. als wahr 
oder falsch) auswerten können. Soll eine Bedingung auf mehr als zwei Ausprägungen 
geprüft werden, so müssen in Flowcharts mehrere Verzweigungen kaskadiert ein- 
gesetzt werden. Die ausgehenden Verbindungen werden mit der jeweiligen Ausprägung 
beschriftet, bei der nach der Prüfung der Bedingung das Programm fortgesetzt wird. Eine 
wiederholte Ausführung von Operationen (etwa solange noch Dokumente vorhanden 
sind, die bearbeitet werden müssen) wird abgebildet, in dem mit einer ausgehenden Ver- 
bindung zu einer früheren Operation zurückgesprungen wird. Die andere ausgehende 
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Abb. 3.1 Notationselemente von Flowcharts 
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Verbindung leitet dann zu jenem Ablaufteil über, der ausgeführt wird, sobald die wieder- 
holte Ausführung abgeschlossen ist. 

Neben diesen Grundelementen bieten Flowcharts in manchen Varianten noch spe- 
zielle Sprachelemente, die vor allem der Abbildung von spezifischen Operationen im 
Anwendungsgebiet dienen (bei Computersystemen etwa Ein- oder Ausgabeoperationen). 
Für das konzeptionelle Verständnis von Flowcharts und vor allem deren Anwendung in 
der Geschäftsprozessmodellierung sind diese jedoch nicht relevant. 

Im Folgenden betrachten wir die Verwendung der Notationselemente anhand von Bei- 
spielen aus der Geschäftsprozessmodellierung. Die verwendete Notation orientiert sich 
an den durch das ANSI bzw. die DIN in den 1960er-Jahren festgelegten Symbolik. 


3.2.2 Beispiele 


Dieses Beispiel (siehe Abb. 3.2) zeigt einen Prozess mit einer einzelnen Operation, in 
der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, 
nachdem die Bearbeitung des Antrags abschlossen wurde. 

Im obenstehenden Beispiel (siehe Abb. 3.3) ist der Prozess um eine Entscheidung 
erweitert. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Tref- 
fen einer Entscheidung über dessen Bestätigung oder Ablehnung. Das Bestätigen bzw. 
Ablehnen selbst sind wiederum Operationen. Die ausgehenden Verbindungen werden 
zusammengeführt, nachdem die alternativen Zweige abgeschlossen sind. 

Ist es nun notwendig, eine Entscheidung zu treffen, die mehr als zwei mögliche Aus- 
gänge hat, muss dieser Sachverhalt in Flowcharts mittels kaskadierter Entscheidungs- 
elemente dargestellt werden. Dies ist im obenstehenden Beispiel (siehe Abb. 3.4) zu 
sehen. Offensichtlich handelt es sich bei unseren Anträgen um Investitionsbegehren. 
Die erste Entscheidung prüft nun, ob die Investition weniger als EUR 1000,- kostet. Ist 
dies der Fall, wird der Antrag direkt bestätigt. Ist dies nicht der Fall, kommt es zu einer 


Abb. 3.2 Einfaches N 


Flowchart ( Start 


Antrag prüfen 


| 
| Ende \ 
W 


76 3 Modellierungssprachen 


Antrag prüfen 


Positive 
Entscheidung? 


Antrag 


Antrag 
| ablehnen 


bestätigen 


Abb. 3.3 Flowchart mit Entscheidung 
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Abb. 3.4 Flowchart mit kaskadierten Entscheidungen 
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zweiten Entscheidung. Diese prüft, ob die Antragssumme kleiner als EUR 10.000,- ist. 
Wenn dies der Fall ist, liegt die Antragssumme zwischen EUR 1000,- und EUR 9999,-, 
was zu einer Prüfung der Beilagen zum Antrag führt. Wenn die Antragssumme nicht 
kleiner als EUR 10.000,- ist, also EUR 10.000,- oder mehr beträgt, wird der Antrag 
weitergeleitet. Wir erfahren hier nichts über das Ziel der Weiterleitung, da Flowcharts 
dafür keine Notationselemente anbieten. 

Wie bereits erwähnt, können Verzweigungen auch genutzt werden, um Teile eines 
Prozesses wiederholt abzuarbeiten. Dazu wird die Entscheidung am Ende des zu wieder- 
holenden Teils eingefügt und ein ausgehender Zweig vor die erste Operation des zu 
wiederholenden Teils zurückgeführt. Der andere ausgehende Zweig führt den Prozess 
nach der wiederholten Abarbeitung weiter. Im obenstehenden Beispiel (siehe Abb. 3.5) 
werden also solange Anträge bearbeitet, solange noch weitere Anträge vorhanden sind. 

Wichtig ist hier zu verstehen, dass zumindest ein Antrag bearbeitet werden muss, 
bevor es zu einer Entscheidungsprüfung kommt. Soll der Prozess enden können, wenn 
gar keine Anträge vorliegen, müsste eine zusätzliche Entscheidung am Beginn des Pro- 
zesses eingefügt werden (‚Anträge vorhanden?“), von der eine ausgehende Verbindung 

„nein“) direkt zum Ende des Prozesses führt. Die andere ausgehende Kante (,ja“) 
würde zum bereits abgebildeten Prozessablauf weiterführen. 


3.2.3 Einordnung 


Flowcharts bieten eine einfache Möglichkeit, Geschäftsprozesse hinsichtlich der logi- 
schen Abfolge der enthaltenen Aktivitäten abzubilden. Andere Aspekte eines Geschäfts- 
prozesses, wie Daten oder Verantwortlichkeiten, sind im Sprachumfang nicht vorgesehen 
und können deshalb nicht abgebildet werden. 

Die Abbildung von parallelen Abläufen ist ebenfalls nicht möglich. Dies ist ein maß- 
geblicher Grund dafür, dass Flowcharts zum Teil von aktuelleren Sprachen wie UML 
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Abb. 3.5 Flowchart mit Schleife 
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Aktivitätsdiagrammen oder BPMN abgelöst werden, die dafür Konstrukte anbieten. 
Da Flowcharts keine Verantwortlichkeiten abbilden lassen, ist auch die Abbildung von 
Kommunikationsvorgängen nicht möglich — diese Einschränkung wurde ebenfalls durch 
modernere Sprachen adressiert, die wir in den folgenden Abschnitten behandeln. 


3.3 _Ereignisgesteuerte Prozessketten 


Ereignisgesteuerte Prozessketten (EPKs) waren lange Zeit in Europa der de-facto Stan- 
dard zur Abbildung in Geschäftsprozessen in der industriellen Praxis. Sie wurden als Teil 
des in Abschn. 2.5.1.4 bereits vorgestellten ARIS-Konzeptes spezifiziert und dienen dort 
als Mittel zur Abbildung von Modellen der Steuerungssicht einer Organisation — also 
jener Sicht, die sich mit den Abläufen in einer Organisation und der dort stattfindenden 
Verknüpfung zwischen deren unterschiedlichen Ressourcen beschäftigt. Ressourcen kön- 
nen hier im Speziellen aus aktiver Sicht die handelnden Organisationsmitglieder bzw. 
-einheiten, sowie aus passiver Sicht die benötigten und manipulierten Daten sein. 

Die EPK verknüpft die Funktionen, die eine Organisation ausführen kann, auf 
Basis von auftretenden Ereignissen miteinander. Das grundlegende Abbildungsprinzip 
ist dabei, dass eine Funktion immer durch ein Ereignis ausgelöst wird — dass also vor 
einer Funktion immer ein Ereignis modelliert werden muss, um feststellen zu können, 
ob mit der Ausführung einer Funktion begonnen werden kann. In der umfassenderen 
Variante „erweiterte EPK“ (eEPK) sind den Funktionen die für deren Ausführung rele- 
vanten Elemente der anderen ARIS-Sichten zugeordnet. Insbesondere können aus 
der Organisationssicht die ausführenden Akteure, Rollen oder Organisationseinheiten 
zugeordnet werden, aus der Datensicht die relevanten Dokumente oder Datenobjekte. 
Wenn eine Funktion eine abrechenbare Leistung erbringt, so kann diese durch Elemente 
der Leistungssicht abgebildet werden. 

Neben der Abbildung von Entscheidungen im abgebildeten Ablauf ermöglicht die 
EPK auch die Abbildung von parallelen Abläufen in einen Geschäftsprozess. Dafür 
stellt sie zusätzliche Notationselemente zur Verfügung, die sich an den Operatoren der 
Bool’schen Logik orientieren — mittels UND-Konnektoren können parallel ablaufende 
Prozesszweige abgebildet werden, der XOR-Konnektor dient dazu, Entscheidungen 
abzubilden, bei denen genau eine Alternative gewählt werden muss (dies entspricht dem 
Entscheidungselement bei Flowcharts). Mit dem ODER-Konnektor können Prozesse 
abgebildet werden, bei denen aus einer oder mehreren Alternativen gewählt werden kann. 


3.3.1 Notationselemente der EPK 


Das Grundelement zur Beschreibung von Geschäftsprozessen ist bei EPKs, ähnlich wie 
bei Flowcharts, die Funktion (bei Flowcharts: Operation). Die Abfolge der Funktionen in 
einem Prozess wird aber nicht ausschließlich über Verbindungspfeile festgelegt. Durch 
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den Einsatz von Ereignissen wird der Ablauf hier genauer spezifiziert. Jede Funktion 
wird durch ein Ereignis ausgelöst und erzeugt selbst ein oder mehrere Ereignisse. Ein 
Prozess wird also durch eine Folge von Ereignissen und Funktionen dargestellt, wobei 
sich Ereignisse und Funktionen immer abwechseln. Bei der Benennung muss hier darauf 
geachtet werden, dass Funktionen einen Vorgang beschreiben (etwa „Antrag prüfen“), 
während Ereignisse einen Zustand beschreiben (etwa „Antrag bestätigt‘ oder „Antrag 
abgelehnt“). 

Eine EPK beginnt und endet immer mit einem Ereignis. Ereignisse, die einen Pro- 
zess auslösen, sind Start-Ereignisse. Ereignisse, die den Abschluss eines Prozesses 
beschreiben, sind Ende-Ereignisse. Folgeprozesse können durch Ende-Ereignisse eines 
vorangegangenen Prozesses ausgelöst werden, d.h. ein Ende-Ereignis kann in einem 
anderen Prozess ein auslösendes Start-Ereignis darstellen. 

Durch den Einsatz unterschiedlicher Konnektoren können nun in Kombination mit 
Ereignissen verschiedene Ablaufvarianten eines Prozesses innerhalb eines Modells 
abgebildet oder auch die Möglichkeit zur parallelen Ausführung von Funktionen (wenn 
diese nicht voneinander abhängig sind) dargestellt werden (siehe Abb. 3.6). Es lassen 
sich der UND-, ODER- und XOR-Konnektor unterscheiden. 

Wird ein UND-Konnektor mit mehreren ausgehenden Verbindungen verwendet, so 
bedeutet dies, dass alle ausgehenden Pfade parallel durchlaufen werden. Diese werden 
dann in der Regel an einer zeitlich bzw. kausal nachgelagerten Stelle wieder mit einem 
weiteren UND-Konnektor zusammengeführt. Die darauf folgende Funktion wird erst 
ausgeführt, wenn alle der zusammengeführten Pfade abgeschlossen sind. 

Ein ODER-Konnektor mit mehreren ausgehenden Kanten zeigt an, dass ein oder meh- 
rere der folgenden Pfade parallel durchlaufen werden. Diese Pfade werden zumeist an 
einer späteren Stelle wiederum mit einem ODER-Konnektor zusammengeführt, wobei 
der dann folgende Prozessschritt erst zu einem Zeitpunkt durchgeführt wird, wenn 
genau die Pfade, die bei der entsprechenden ODER-Verzweigung ausgewählt wurden, 
abgearbeitet sind. Wichtig ist hier, dass die zu aktivierenden Pfade zum Zeitpunkt des 
Eintreffens beim Konnektor ausgewählt werden müssen. Hinter jedem ODER-Konnektor 
muss sich auf jedem Pfad ein Ereignis befinden, das durch die vorangegangene Funktion 
ausgelöst werden könnte. Es werden jene Pfade aktiviert, deren erste Ereignisse tatsäch- 
lich eingetreten sind. 

Ein XOR-Konnektor steht schließlich für ein „exklusives Oder“ bzw. ein „ent- 
weder, oder“. Die Verwendung eines XOR-Konnektors mit mehreren ausgehenden Kan- 
ten bedeutet, dass bei der Durchführung des Prozesses genau einer der folgenden Pfade 
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Abb. 3.6 Notationselemente von EPKs 
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ausgewählt wird. Er eignet sich also zur Abbildung von einander ausschließenden Alter- 
nativen in der Prozessabarbeitung. Bei der Zusammenführung dieser Pfade mit einem 
XOR-Konnektor wird der folgende Schritt dann ausgeführt, wenn der ausgewählte Pfad 
fertig durchlaufen wurde. Auch bei einem XOR-Konnektor muss sich auf jedem Pfad 
ein Ereignis befinden, das durch die vorangegangene Funktion ausgelöst werden könnte. 
Diese Ereignisse müssen einander ausschließen. Es wird jener Pfade aktiviert, dessen ers- 
tes Ereignis tatsächlich eingetreten ist. Im Gegensatz zu Flowcharts ist es hier möglich, 
auch mehr als zwei Alternativen zu beschreiben, solange die eingesetzten Ereignisse ein- 
ander ausschließen. 


3.3.2 Beispiele zur EPK 


Wir verwenden hier vorerst die gleichen Beispiele, wie sie für Flowcharts angegeben 
wurden, um die Unterschiede in der Notation zu visualisieren. 

Dieses Beispiel (siehe Abb. 3.7) zeigt einen Prozess mit einer einzelnen Funktion, in 
der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, 
nachdem der Antrag geprüft wurde. 

Im obenstehenden Beispiel (siehe Abb. 3.8) ist der Prozess um eine Entscheidung 
erweitert. Der Antrag wird geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen 
einer Entscheidung auf Basis dessen positiver oder negativer Beurteilung. Das Bestätigen 
bzw. Ablehnen selbst sind ebenfalls Funktionen. Die ausgehenden Verbindungen wer- 
den mit einem XOR-Konnektor zusammengeführt, nachdem die alternativen Zweige 
abgeschlossen sind. 

Die Darstellung von Entscheidungen, die mehr als zwei mögliche Ausgänge haben, 
ist hier nun einfacher möglich als bei Flowcharts (siehe Abb. 3.9). Dem XOR-Konnek- 
tor werden in diesem Fall drei Ereignisse nachgelagert, die sich alle auf die Investitions- 
summe beziehen und einander ausschließen. 
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Abb. 3.7 Einfache EPK 
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Abb. 3.8 EPK mit Verzweigung 


Der XOR-Konnektor kann auch genutzt werden, um Teile eines Prozesses wieder- 
holt abzuarbeiten. Dazu wird der Konnektor am Ende des zu wiederholenden Teils 
eingefügt und ein ausgehender Zweig auf das Ereignis zurückgeführt, das den zu wieder- 
holenden Teil auslöst. Der andere ausgehende Zweig führt den Prozess nach der wieder- 
holten Abarbeitung weiter und muss dementsprechend zu einem Ereignis führen, das den 
Abbruch der Wiederholung auslöst. Im obenstehenden Beispiel (siehe Abb. 3.10) werden 
also solange Anträge bearbeitet als Anträge vorhanden sind. 

Der UND-Konnektor kann zum Einsatz kommen, wenn zwei Funktionen unabhängig 
voneinander ausgeführt werden können. Der im obigen Beispiel (siehe Abb. 3.11) 
modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich unabhängig vom 
Antrag geprüft werden können. Ist dies nicht der Fall, müssten die beiden Funktionen 
sequenziell angeordnet werden. Aus Sicht der Modellerstellung ist hier anzumerken, 
dass dem UND-Konnektor im Gegensatz zu den anderen Konnektoren nicht unmittelbar 
Ereignisse folgen müssen, da ja keine Entscheidung getroffen wird, sondern in jedem 
Fall alle ausgehenden Zweige aktiviert werden. 


82 3 Modellierungssprachen 


Antrag 
ein- 
gelangt 


Antrag prüfen 


Investition 
>999 & 
<10000 

EUR 


Investition 
>9999 
EUR 


Investition 
<1000 
EUR 


Antrag Beilagen Antrag 
bestätigen prüfen weiterleiten 


Abb. 3.9 EPK mit Verzweigung in drei Alternativen 
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Abb. 3.10 EPK mit Schleife 
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Abb. 3.11 EPK mit UND-Konnektor und parallel ablaufenden Zweigen 


Die obige Abbildung (siehe Abb. 3.12) zeigt ein Beispiel für den Einsatz des 
ODER-Konnektors. Hier gehen wir davon aus, dass ein Antrag Angebote oder Stellung- 
nahmen oder beides enthalten kann (aber zumindest Angebote oder Stellungnahmen 
enthalten muss). Wären Angebote und Stellungnahmen vollkommen optional (könn- 
ten also beide fehlen), würde deren grundsätzliche Notwendigkeit mit einem vor- 
gelagerten XOR-Konnektor und entsprechenden Ereignissen zu prüfen sein. Alternativ 
könnte nach dem ODER-Konnektor ein zusätzlicher Zweig mit einem Ereignis „Antrag 
alleine genügt“ eingefügt werden. In beiden Fällen muss darauf geachtet werden, dass 
die Bedingung, dass sich Ereignisse und Funktionen auf allen Pfaden durch den Prozess 
abwechseln, nicht verletzt wird. Falls nicht anders möglich, muss dies durch eine „Dum- 
my“-Funktion, die keine Aktivität verursacht, gewährleistet werden. 


3.3.3 Ergänzende Notationselemente der eEPK 


Die eEPK ergänzt nun den in einer EPK abgebildeten Geschäftsprozess um Information 
über dessen Ausführungskontext. Insbesondere werden hier den Funktionen Verantwort- 
lichkeiten und Ressourcenbedarf zugeordnet. Die grundsätzlichen Regeln einer EPK 
bleiben wie oben beschrieben in Kraft. Die zusätzlichen Elemente können Funktionen 
zugeordnet werden. Ereignisse sind nicht betroffen. Wir verzichten an dieser Stelle auf 
eine vollständige Beschreibung der möglichen Elemente und führen nur die gängigsten 
an (siehe Abb. 3.13). 

Verantwortlichkeiten werden durch Organisationale Einheiten abgebildet. Solche 
Einheiten sind üblicherweise nicht konkrete Personen, sondern werden abstrakt durch 
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Abb. 3.13 Zusätzliche Notationselemente in eEPKs 


die Benennung von Rollen (etwa: Geschäftsführung) oder Abteilungen (etwa: Finanz- 
buchhaltung) angeführt. Dadurch wird gewährleistet, dass die Spezifikation eines Pro- 
zesses von der Verfügbarkeit konkreter Personalressourcen unabhängig ist und erst zur 
Durchführungszeit konkrete Personen zugewiesen werden müssen. Die Zuordnung zu 
einer Funktion erfolgt durch ungerichtete Linien. Eine organisationale Einheit kann so 
mehreren Funktionen zugeordnet werden. Auch ist es möglich, organisationale Einheiten 
mehrfach anzuführen, wenn die Prozessdarstellung dadurch übersichtlicher wird. 

In ähnlicher Form werden Anwendungssysteme modelliert. Sie kennzeichnen die Not- 
wendigkeit, bei der Ausführung einer Funktion ein bestimmtes IT-System einzusetzen 
(z.B. ein ERP-System oder eine Datenbank). Sie werden Funktionen ebenfalls mit 
ungerichteten Linien zugeordnet. 
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Informationsobjekte werden dazu verwendet, um die Datenverarbeitung in einem 
Geschäftsprozess darzustellen. Ein Informationsobjekt kann beliebig umfassend sein 
(also ein einzelner Wert ebenso wie ein vollständiges Dokument) und wird einer Funk- 
tion immer mittels einem gerichteten Pfeil zugeordnet, der den Datenfluss beschreibt. 
Endet der Pfeil bei der Funktion, bedeutet dies, dass das Informationsobjekt zur Durch- 
führung der Funktion benötigt wird. Endet der Pfeil beim Informationsobjekt, so 
bedeutet dies, dass es durch die Funktion erzeugt oder verändert wird. Ein Informations- 
objekt kann dabei mehrere ein- und ausgehende Verbindungen haben, wodurch sowohl 
dessen Entstehung als auch dessen Verwendung in einem Geschäftsprozess beschrieben 
werden kann. 


3.3.4 Beispiele zur eEPK 


Zur Illustration von eEPKs ergänzen wir eines der oben angeführten Beispiele um den 
stattfindenden Datenfluss sowie die benötigten Personal-Ressourcen. Anwendungs- 
systeme würden analog zur Verwendung von organisationalen Einheiten modelliert wer- 
den (siehe Abb. 3.14). 
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Abb. 3.14 Beispiel für eine eEPK 
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Hinsichtlich des Datenflusses erkennen wir nun, dass zum Prüfen des Antrags der 
eigentliche Antrag vorhanden sein muss. Diese Prüfung führt nicht nur zur positi- 
ven oder negativen Beurteilung eines Antrags im Prozessablauf, sondern auch zu einem 
Informationsobjekt, in dem die Beurteilung gespeichert ist. Im Falle einer negativen 
Beurteilung wird dieses Informationsobjekt benötigt, um die Ablehnung zu erstellen (wir 
können also annehmen, dass die Ablehnung eine inhaltliche Begründung enthält). Im Falle 
der Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt — wir 
können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt. 

Hinsichtlich der Verantwortlichkeiten erkennen wir nun, dass mehrere organi- 
sationale Einheiten am Prozess beteiligt sind. Während die Antragsprüfung durch 
einen Sachbearbeiter erfolgt, ist für die endgültige Bestätigung oder Ablehnung der 
Abteilungsleiter zuständig. Wichtig ist hier, dass die Ereignisse, auf Basis derer die Ent- 
scheidung getroffen wird, durch die Funktion „Antrag prüfen“ ausgelöst werden, für die 
der Sachbearbeiter zuständig ist. 


3.3.5 Einordnung 


Die EPK bietet umfassendere Möglichkeiten zur Abbildungen von Geschäftsprozessen 
als Flowcharts. Gemein ist ihnen die Orientierung an den Abläufen innerhalb einer 
Organisation als primäres Strukturierungsmerkmal des Geschäftsprozesses (d.h. alle 
im Modell abgebildete Information ist an der Beschreibung des Prozessablaufs ver- 
ankert). Dies ist zwar naheliegend, wenn ein organisationaler Prozess beschrieben 
wird, aber — wie wir später sehen werden — nicht unbedingt die einzige Möglichkeit. 
Andere Modellierungssprachen nutzen Akteure oder Daten als primäre Strukturierungs- 
merkmale, an denen alle anderen Informationen verankert werden und machen so 
Aspekte eines Prozesses sichtbar, die in (e)EPKs nur implizit abgebildet werden können 
(wie etwa der Übergang von Verantwortlichkeiten im Prozess und der dabei notwendigen 
Kommunikation zwischen den Akteuren). 

Die Notwendigkeit, Funktionen und Ereignisse einander immer abwechseln zu las- 
sen, führt in EPKs zu sehr umfangreichen und zum Teil nur schwer verständlichen 
Modellen. Außerdem birgt sie das Risiko, Modellierende bei der Erstellung der Modelle 
dazu zu verleiten, Trivial-Ereignisse zu formulieren, die dem Modell keine Information 
hinzufügen (etwa: Funktion: „Aufgabe ausführen“, Ereignis: „Aufgabe ausgeführt“). 
Korrekt eingesetzt, bietet diese Systematik aber Vorteile: Einerseits können Prozesse 
exakter beschrieben und abgegrenzt werden als etwa mit Flowcharts, andererseits erlaubt 
die EPK eine Verknüpfung zwischen der Sicht auf die Fähigkeiten einer Organisation 
(ihrer Funktionen) und der Sicht darauf, wie sie mithilfe ihrer Fähigkeiten auf externe 
Reize oder Ereignisse innerhalb der Organisation selbst reagiert. So können organisatio- 
nale Fähigkeiten generisch beschrieben und mehrfach in Prozessen eingesetzt werden, 
wodurch Ineffizienzen durch Replikation vermieden werden. 

Aus pragmatischer Sicht hat sich in der Praxis jedoch gezeigt, dass sowohl die Spezi- 
fikation generischer Funktionen als auch prozessspezifischer Ereignisse nicht immer 
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in der notwendigen Gesamtheit umsetzbar ist. Modernere Ansätze, wie die im folgen- 
den behandelten Aktivitätsdiagramme oder die BPMN, kennen deshalb zwar nach wie 
vor das Konzept von Ereignissen, setzen diese aber nur ein, wenn tatsächlich auf einen 
externen Reiz (wie eine eingehende Nachricht, einen Fehler, oder einen Zeitablauf) ein- 
gegangen werden soll. 

In Abgrenzung zu den Modellierungssprachen mit technisch orientierter Entstehungs- 
geschichte (wie Flowcharts oder die im nächsten Abschnitt beschriebenen Aktivitätsdia- 
gramme) verfolgen die eEPK und das umgebende ARIS-Framework als ein ursprünglich 
aus der Betriebswirtschaftslehre stammendes Konzept einen umfassenderen Ansatz zur 
Beschreibung von Geschäftsprozessen. Die Berücksichtigung von Daten, Verantwortlich- 
keiten, aber auch Zielen oder Leistungen (die hier nicht diskutiert wurden) ermöglicht 
insgesamt eine umfassende Modellierung von Geschäftsprozessen, die bis heute Einfluss 
auf die Gestaltung von Modellierungssprachen zur Abbildung organisationaler Phäno- 
mene (wie Geschäftsprozessen oder Unternehmensarchitekturen) hat. 


3.4 UML Aktivitätsdiagramme 


Das Aktivitätsdiagramm wurde als Teil der UML (Unified Modeling Language) defi- 
niert, die eine Sammlung von Diagrammen enthält, die zur Spezifikation von Software- 
systemen geeignet sind. Das Aktivitätsdiagramm dient dabei analog zum Flowchart zur 
Abbildung des Verhaltens eines Softwaresystems, stellt aber ob seiner jüngeren Ent- 
stehungsgeschichte auch Elemente zur Abbildung verteilter und paralleler Prozessabläufe 
zur Verfügung. Wie das Flowchart ist auch das Aktivitätsdiagramm zur Abbildung orga- 
nisationaler Abläufe, also von Geschäftsprozessen, geeignet. Während dieses bis heute 
zu diesem Zweck eingesetzt wird, hat sich der Fokus im Bereich der Geschäftsprozess- 
modellierung stark hin zur BPMN (Business Process Modeling and Notation) verschoben. 
Diese wurde vom gleichen Standardisierungsgremium wie die UML spezifiziert und hat 
viele Elemente des Aktivitätsdiagramms übernommen. Die BPMN fokussiert explizit auf 
die Anforderungen der Geschäftsprozessmodellierung und der dort abzubildenden organi- 
sationalen Aspekte, die wir bereits im Rahmen der EPKs diskutiert haben. 


3.4.1 Notationselemente 


Ein Aktivitätsdiagramm beschreibt per Definition immer eine Aktivität, die sich aus 
einzelnen Aktionen zusammensetzt („Aktivität wird hier also analog zu „Prozess“ ver- 
wendet). Eine Aktion entspricht einer Operation bei Flowcharts oder einer Funktion bei 
EPKs (siehe Abb. 3.15). 

Eine Aktivität beginnt üblicherweise mit einem Startknoten und endet mit einem 
Endknoten (analog zu den Terminierungselementen bei Flowcharts). Zwischen die- 
sen Knoten werden die enthaltenen Aktionen angegeben und durch Ablaufpfeile in die 
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durchzuführende Reihenfolge gebracht. Zur Beeinflussung des Ablaufs ist es möglich, 
Entscheidungselemente einzufügen. Entscheidungen können beliebig viele ausgehende 
Zweige haben, deren Aktivierungsbedingungen sich einander ausschließen müssen. Die 
Bedingungen werden an den ausgehenden Verbindungen angeführt. Die Semantik des 
Entscheidungssymbols entspricht dem XOR in der EPK - für den ODER-Konnektor gibt 
es in Aktivitätsdiagrammen keine Entsprechung. 

Um voneinander unabhängig parallel ausführbare Prozessteile abzubilden, bietet das 
Aktivitätsdiagramm das Split/Join-Element. Zum Aufspalten des Ablaufs eingesetzt, 
kann es beliebig viele ausgehende Verbindungen haben, die alle gleichzeitig aktiviert 
werden. Die so angelegten Zweige sollten durch ein Join wieder zusammengeführt wer- 
den. Der Ablauf wird erst fortgesetzt, sobald alle Zweige abgearbeitet sind. 

Signale dienen der Kommunikation zwischen Prozessteilen in unterschiedlichen 
Aktivitäten (also in unterschiedlichen Diagrammen) oder innerhalb einer Aktivität, wenn 
Information für spätere Prozessteile bereitgestellt werden soll. Sie werden wie Aktionen 
in den Kontrollfluss eingebaut. Modelle müssen nicht immer vollständige Signalpaare 
(also gesendete und empfangene Signale) enthalten, sondern können auch Signale für 
nicht abgebildete Prozesse bereitstellen (also nur ein gesendetes Signal enthalten), oder 
dieses von einem nicht abgebildeten Prozess entgegennehmen (also nur ein empfangen- 
des Signal enthalten). Empfangene Signale können außerdem eine Aktivität auslösen und 
damit den Startknoten in einem Diagramm ersetzen. 

Das Aktivitätsdiagramm bietet auch Elemente, um Verantwortlichkeiten und Daten- 
flüsse abzubilden (siehe Abb. 3.16). Verantwortlichkeiten werden mittels Partitionen 
abgebildet. Partitionen sind Elemente, die Teile eines Aktivitätsdiagramms umschlie- 
ßen und damit festlegen, dass alle Elemente, insbesondere Aktionen, die von ihnen 
umschlossen sind, in die Verantwortlichkeit der angeführten organisationalen Einheit 
(oder bei Softwaresystemen der Systemkomponente) fällt. Wenn Partitionen eingesetzt 
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Abb. 3.17 Einfaches 
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werden (was nicht verpflichtend ist), so sollten alle Elemente des Aktivitätsdiagramms 
von genau einer der abgebildeten Partitionen umschlossen werden. Überlappungen sind 
nicht erlaubt, Aktionen außerhalb einer Partition sollten vermieden werden. 

Datenobjekte werden in Aktivitätsdiagrammen direkt im Kontrollfluss, und zwar 
zwischen Aktionen modelliert. Sie können damit (nur) dafür eingesetzt werden, den 
Informationsfluss zwischen zwei aufeinanderfolgenden Aktionen abzubilden. Wird ein 
Datenobjekt erst später im Prozessablauf wieder benötigt, so müsste dieses im Kontroll- 
fluss über alle dazwischenliegenden Aktionen weitergegeben oder mittels eines Signals 
übergeben werden. 


3.4.2 Beispiele 


Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungs- 
sprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Bei- 
spiele. 

Dieses Beispiel (siehe Abb. 3.17) zeigt eine Aktivität mit einer einzelnen Aktion, in 
der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Die Aktivität endet, 
nachdem die Bearbeitung des Antrags abschlossen wurde. 

Im obenstehenden Beispiel (siehe Abb. 3.18) ist der Prozess um eine Entscheidung 
mit drei möglichen Ausgängen erweitert, die einander ausschließen. Der Antrag wird 
geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über die 
weitere Bearbeitung. 

Auch hier können wir Verzweigungen nutzen, um Teile eines Prozesses wieder- 
holt abzuarbeiten (siehe Abb. 3.19). Dazu wird die Entscheidung am Ende des zu 
wiederholenden Teils eingefügt und ein ausgehender Zweig zu einer schließenden Ent- 
scheidung vor die erste Operation des zu wiederholenden Teils zurückgeführt (eine 
schließende Entscheidung dient der Zusammenführung und hat mehrere eingehende und 
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nur eine ausgehende Verbindung). Der andere ausgehende Zweig der öffnenden Ver- 
zweigung führt den Prozess nach der wiederholten Abarbeitung weiter. 

Das Split/Join-Element kann zum Einsatz kommen, wenn zwei Aktionssequenzen 
unabhängig voneinander ausgeführt werden können. Der im obigen Beispiel (siehe 
Abb. 3.20) modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich 
unabhängig vom Antrag geprüft werden können. Ist dies nicht der Fall, müssten die bei- 
den Funktionen sequenziell angeordnet werden. Beim zusammenführenden Join-Element 
wird auf den Abschluss beider eingehender Zweige gewartet, bevor der Prozess fort- 
gesetzt wird. 

Das obige Beispiel (siehe Abb. 3.21) zeigt den Einsatz von Partitionen, Datenobjekten 
und Signalen. Mittels Partitionen werden die Verantwortlichkeiten im Prozess abgebildet. 
Dessen Auslösung durch ein empfangenes Signal bildet explizit ab, dass die Ausführung 
erst dann startet, wenn ein Antrag einlangt (das hatten wir bei Flowcharts und den ande- 
ren Beispielen zum Aktivitätsdiagramm bislang immer implizit angenommen, aber im 
Gegensatz zu EPKs nie im Modell abbilden können). Gesendete Signale werden ein- 
gesetzt, um die Bestätigung oder Ablehnung an den Empfänger (der hier nicht abgebildet 
ist) zu übermitteln. Die Beurteilung des Antrags wird nur im Falle einer negativen 
Beurteilung als Datenobjekt zur Aktion „Antrag ablehnen“ übergeben — wir können folg- 
lich annehmen, dass die Ablehnung eine inhaltliche Begründung enthält. Im Falle der 
Bestätigung des Antrags wird das Datenobjekt „Beurteilung“ nicht mehr benötigt — wir 
können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt. 
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Abb. 3.21 Aktivitätsdiagramm mit Partitionen und Datenobjekten und Signalen 


3.4.3 Einordnung 


Aktivitätsdiagramme vereinen mit gewissen Einschränkungen die Einfachheit der 
Flowchart-Notation mit der Ausdrucksstärke von EPKs. Sie erlauben es, die Behandlung 
von Daten im Prozess darzustellen und führen mit Partitionen ein Mittel zur über- 
sichtlichen Abbildung von Verantwortlichkeiten ein. Die Verfügbarkeit von Signa- 
len erlaubt im Gegensatz zu den bisher behandelten Sprachen erstmals eine Abbildung 
von Kommunikationsvorgängen zwischen Prozessbeteiligten oder mit der Umwelt des 
abgebildeten Prozesses. 

Das Fehlen eines Elements, das dem ODER-Konnektor in der EPK entspricht, stellt 
zwar eine Einschränkung dar, die allerdings in der Praxis selten schlagend wird, da im 
realen Umfeld zumeist einander ausschließende Alternativen oder vollständig von- 
einander unabhängige Ausführungszweige vorkommen. Insgesamt stellen Aktivitätsdia- 
gramme also ein geeignetes Mittel zur Abbildung von Geschäftsprozessen dar, vor allem 
wenn die Zielgruppe für die Modellverwendung einen informationstechnischen Hinter- 
grund hat und mit der Notation bereits vertraut ist. Für andere Zielgruppen ist aufgrund 
der flexibleren Einsetzbarkeit und der höheren Ausdrucksstärke für Geschäftsprozess- 
modellierung die BPMN vorzuziehen, die wir im nächsten Abschnitt behandeln werden. 


3.5 BPMN 


Die BPMN - Business Process Modeling (and) Notation — wurde 2002 bei IBM ent- 
wickelt und nachfolgend von der BPMI (Business Process Management Initiative) 
veröffentlicht. Ziel war es, der Vielzahl an Prozessmodellierungssprachen, die im aka- 
demischen Bereich und in der industriellen Praxis eingesetzt wurden, einen universell 
verwendbaren Standard entgegen zu setzen. Dieser sollte die wesentlichen Eigenschaften 
der gängigsten Sprachen übernehmen und es ermöglichen, neben der Dokumentation 
von Geschäftsprozessen auch Modelle zu erstellen, die unmittelbar zur IT-unterstützten 
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Ausführung geeignet sind. Die BPMI wiederum wurde 2005 von der OMG (Object 
Management Group) übernommen bzw. fusionierte mit dieser. Dadurch wurde BPMN 
zum OMG-Standard und ergänzt damit die bereits erwähnte UML (Unified Modelling 
Language). 

Im dritten Quartal 2010 wurde der neue Standard BPMN 2.0 veröffentlicht. Dieser 
Standard umfasst unterschiedliche Diagrammtypen: das Choreografie-, das Konversati- 
ons- und das Kollaborationsdiagramm. Im Folgenden betrachten wir die grundlegenden 
Elemente der BPMN 2.0, die die Abbildung von Geschäftsprozessen auf fachlicher 
Ebene ermöglichen. 

Die BPMN konzentriert sich auf Geschäftsprozesse, welche sie als eine zeitlich logi- 
sche Abfolge von Aktivitäten (Aufgaben) darstellt und hinsichtlich der organisationalen 
Verantwortlichkeiten strukturiert. Die Darstellung von Daten ist nur ansatzweise und im 
Kontext von Prozessabläufen vorgesehen. 


3.5.1 Notationselemente zur Modellierung von Abläufen 


Prozessdiagramme, die mit der BPMN erstellt wurden, werden „Business Process 
Diagrams (BPD)“ genannt. Das BPD orientiert sich in seinen Kernelementen an 
Aktivitätsdiagrammen, die um Elemente ergänzt sind, die eine potenziell komplexe 
Ablaufsteuerung in Geschäftsprozesse abbildbar machen (siehe Abb. 3.22). 

Im Prinzip müssen in einem Prozess bestimmte Dinge getan werden (Aufgaben), 
möglicherweise aber nur unter bestimmten Bedingungen (Gateways), und es können 
Dinge passieren (Ereignisse). Diese drei Flussobjekte werden über Sequenzflüsse mit- 
einander verbunden, jedoch nur innerhalb eines Pool bzw. einer Lane. Pools und Lanes 
sind Konstrukte, um Verantwortlichkeiten in verteilten Geschäftsprozessen darzustellen. 
Sie werden im Folgenden genauer betrachtet. Falls eine Verbindung über Pool-Grenzen 
hinweg erfolgt, wird diese mittels Nachrichtenflüssen modelliert, die wir später detaillie- 
ren werden. 

Ein Prozess besteht aus Aufgaben (Tasks). Nach dem Start eines Prozesses (durch 
ein Ereignis) folgt eine Aufgabe der anderen bis der Prozess endet (durch ein Ereignis). 
Aufgaben können dabei atomar sein (also nicht weiter verfeinert sein), oder als Sub- 
prozess vorliegen. In diesem Fall wird eine Aufgabe durch ein eingebettetes weiteres 
BPD verfeinert, d. h. dessen detaillierter Ablauf dargestellt. Dieser detaillierte Ablauf 
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kann „versteckt“ werden und wird durch ein „+“-Symbol am unteren Rand der Aufgabe 
repräsentiert. 

Ein Prozess beginnt mit einem Start-Ereignis und endet in einem End-Ereignis. Die 
BPMN bietet eine Vielzahl an Möglichkeiten, Ereignisse zu definieren, die einen Prozess 
auslösen, abschließen oder dessen Verlauf beeinflussen können. Diese werden wir später 
näher behandeln. 

An dieser Stelle ist wichtig zu betonen, dass ein Prozess mit einem oder mehre- 
ren Start-Ereignissen beginnen kann und auf jedem Pfad durch den Prozess (siehe 
Sequenzfluss und Gateways weiter unten) mit einem oder mehreren End-Ereignissen 
abgeschlossen werden kann. Von jedem Startereignis muss es einen durchgängigen 
Sequenzfluss zu mindestens einem Endereignis geben. Aufgaben, Gateways oder 
Zwischen-Ereignisse dürfen keine Endpunkte im Prozess sein, benötigen also auch 
immer mindestens einen ausgehenden Sequenzfluss. 

Ein Gateway ist eine Abzweigung im Kontrollfluss. Das exklusive (oder XOR-)Gate- 
way benötigt zu jedem ausgehenden Kontrollfluss eine Bedingung, die sich It. Standard 
immer auf das Ergebnis einer unmittelbar vorangehenden Aufgabe beziehen muss. 

Das parallele (oder AND-)Gateway verfolgt alle ausgehenden Kontrollflüsse 
unabhängig voneinander und parallel weiter. Die verzweigten Kontrollflüsse können 
separat mit Endereignissen beendet oder wieder explizit mit einem weiteren parallelen 
Gateway zusammengeführt werden. Der Kontrollfluss setzt nach dieser Zusammen- 
führung erst fort, wenn alle eingehenden Kontrollflüsse abgeschlossen sind (ent- 
sprechend dem Split/Join-Konzept bei Aktivitätsdiagrammen). 

Das inklusive (oder OR-)Gateway kann einen oder mehrere Pfade weiterver- 
folgen, wobei zur Pfadauswahl jeweils (wie beim exklusiven Gateway) eine Bedingung 
angeführt werden muss. Diese Bedingung muss zum Zeitpunkt der Entscheidung bereits 
prüfbar sein, die notwendigen Daten müssen also in einer der vorangegangenen Auf- 
gaben erzeugt worden sein. 

Für Entscheidungen, die nicht auf Basis bereits existierender Daten getroffen werden 
können, bietet sich die Verwendung des ereignisbasierten Gateways an. Dieses benötigt 
in jedem ausgehenden Zweig unmittelbar nach dem Gateway ein Ereignis (z. B. ein- 
treffende Nachricht oder Timer). Es wird dann jener Zweig (und nur dieser) aktiviert, 
dessen Ereignis zuerst eintritt. Dieses werden wir genauer behandeln, wenn wir die Ver- 
wendung von Ereignissen diskutieren. 


3.5.2 Beispiele zur Modellierung von Abläufen 


Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungs- 
sprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Beispiele. 

Dieses Beispiel (siehe Abb. 3.23) zeigt einen Prozess mit einer einzelnen Aufgabe, in 
der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, 
nachdem die Bearbeitung des Antrags abschlossen wurde. 
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Abb. 3.24 BPMN-Modell mit Verzweigung (3 Zweige) 


Im obenstehenden Beispiel (siehe Abb. 3.24) ist der Prozess um eine Entscheidung 
mit drei möglichen Ausgängen erweitert, die einander ausschließen. Der Antrag wird 
geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über die 
weitere Bearbeitung. In der BPMN ist wichtig, dass die Daten, die als Grundlage einer 
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Abb. 3.25 BPMN-Modell mit Schleife 


Entscheidung verwendet werden, vor dem Gateway explizit erzeugt oder empfangen 
werden. 

Auch hier können wir Verzweigungen nutzen, um Teile eines Prozesses wieder- 
holt abzuarbeiten (siehe Abb. 3.25). Dazu wird die Entscheidung am Ende des zu 
wiederholenden Teils eingefügt und ein ausgehender Zweig zu einer schließenden Ent- 
scheidung vor die erste Operation des zu wiederholenden Teils zurückgeführt (eine 
schließende Entscheidung dient der Zusammenführung und hat mehrere eingehende und 
nur eine ausgehende Verbindung). Der andere ausgehende Zweig der öffnenden Ver- 
zweigung führt den Prozess nach der wiederholten Abarbeitung weiter. Die Anforderung, 
die Entscheidungsgrundlage explizit vor dem Gateway zu schaffen, ist hier durch die 
zusätzliche Aufgabe abgebildet, das Vorhandensein weiterer Anträge zu prüfen. 

Das parallele Gateway kann zum Einsatz kommen, wenn zwei Aufgaben-Sequenzen 
unabhängig voneinander ausgeführt werden können. Der im obigen Beispiel (siehe 
Abb. 3.26) modellierte Prozess ist also nur korrekt, wenn die Beilagen tatsächlich 
unabhängig vom Antrag geprüft werden können. Ist dies nicht der Fall, müssten die bei- 
den Funktionen sequenziell angeordnet werden. Beim zusammenführenden Gateway 
wird auf den Abschluss beider eingehenden Zweige gewartet, bevor der Prozess fort- 
gesetzt wird. 

Das obige Beispiel (siehe Abb. 3.27) zeigt den Einsatz von Pools, Lanes und Daten- 
objekten. Mittels Lanes werden die Verantwortlichkeiten im Prozess abgebildet. Mit den 
bislang eingeführten Elementen der BPMN können wir Kommunikationsvorgänge nicht 
abbilden. Die in Aktivitätsdiagrammen verfügbaren Signale können deshalb vorerst nicht 
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Abb. 3.26 BPMN-Modell mit parallel ablaufenden Zweigen 
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Abb. 3.27 BPMN-Modell mit Pools, Lanes und Datenobjekten 


abgebildet werden, weswegen das Beispiel hier erneut unspezifischer wird. Der Einsatz 
von Nachrichten-Ereignissen, die wir im übernächsten Abschnitt einführen werden, wird 
diesen Mangel aber wieder beheben. Die Beurteilung des Antrags wird nur im Falle einer 
negativen Beurteilung als Datenobjekt zur Aufgabe „Antrag ablehnen“ übergeben — wir 
können also annehmen, dass die Ablehnung eine inhaltliche Begründung enthält. Im Fall 
der Bestätigung des Antrags, wird das Datenobjekt „Beurteilung“ nicht mehr benötigt — 
wir können also annehmen, dass in diesem Fall keine weitere Begründung erfolgt. 
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3.5.3 Notationselemente zur Ablaufsteuerung mit Ereignissen 


Ein Unterscheidungsmerkmal von BPMN zu allen bislang behandelten Sprachen ist das 
hier sehr detailliert und umfassend ausgeführte Ereignis-Konzepte, das eine umfassende 
Kontrolle des Prozessablaufs ermöglicht. 

Ereignisse geben an, dass etwas geschehen ist und sind damit Zeitpunkte im Gegen- 
satz zu Aufgaben, die einen gewissen Zeitraum in Anspruch nehmen. Bis jetzt haben wir 
nur Start- und Endereignisse eingeführt, im Folgenden werden Start-, Zwischen- und 
Endereignisse noch einmal ausführlich beschrieben (siehe Abb. 3.28). 

Ereignisse werden immer mit einem Kreis und üblicherweise einem Symbol dar- 
gestellt. Einfache Kreise kennzeichnen Startereignisse, doppelte Kreislinien Zwischen- 
ereignisse und dicke Kreislinien Endereignisse. Ist kein Symbol angegeben, handelt es 
sich um ein untypisiertes (Blanko-)Ereignis, das in der Regel nur am Beginn oder Ende 
eines Prozesses oder als auslösendes Zwischenereignis zu finden ist. 


3.5.3.1 Startereignisse 

Startereignisse geben den Auslöser für einen Prozess oder Teilprozess an. Häufig 
wird das unbestimmte (Blanko-)Ereignis verwendet, wenn sich der Auslöser aus dem 
Zusammenhang ohnehin ergibt oder wenn der Auslöser nicht näher bekannt ist. 

Wird ein Prozess aufgrund eines Zeitpunkts oder einer Zeitspanne oder eines perio- 
disch stattfindenden Ereignisses ausgelöst, wird zusätzlich das Symbol der Uhr ver- 
wendet. Ein Brief-Symbol wird verwendet, wenn eine Nachricht den Prozess auslöst 
(siehe Abb. 3.29). 

Darüber hinaus gibt es noch Symbole für Bedingungen — der Prozess wird nur aus- 
geführt, wenn die angegebene Bedingung erfüllt ist. Ein Signal ist ein Zeichen, durch 
das der Prozess gestartet wird. Das Fünfeck als Symbol kennzeichnet mehrere mögliche 
Startereignisse, wobei nur eines der Ereignisse eintreten muss, um den Prozess zu starten 
(siehe Abb. 3.30). 

Ein Prozess muss kein einzelnes Startereignis haben, Prozesse können auch mehrere 
alternative Startereignisse haben. 
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3.5.3.2 Endereignisse 

Mit einem Endereignis werden Prozesse beendet, wobei es mit Ausnahme des zeit- 
bezogenen Symbols die Bedingung und den parallelen mehrfachen Auslöser die gleichen 
Symbole gibt wie bei Startereignissen. 

Zusätzlich zu den verschiedenen Arten von Endereignissen gibt es ein Terminie- 
rungs-Endereignis (schwarz gefüllter Kreis mit dicker schwarzer Umrandung), das den 
gesamten Prozess sofort beendet, d. h. die gesamte Prozessinstanz beendet, unabhängig 
davon, ob andere Sequenzen innerhalb des Prozesses zur gleichen Zeit noch durchlaufen 
werden oder nicht. Ein Standard-Endereignis beendet immer nur jenen Prozesszweig, in 
dem es eingefügt ist. Eventuell weitere, noch laufende Prozesszweige werden weiter aus- 
geführt (siehe Abb. 3.31). 

Prozesse können, wie bereits bei den Startereignissen erklärt, mehrere Endereignisse 
haben. Ein Prozess ohne Endereignis ist unvollständig. 


3.5.3.3 Zwischenereignisse & das ereignisbasierte Gateway 
Zwischenereignisse können an irgendeiner Stelle in einem Prozess verwendet werden 
und werden durch einen Kreis mit doppelter Umrandung dargestellt. Sie werden model- 
liert, wenn in einem Prozess ein für andere (Prozesse) relevantes Zwischenergebnis 
erreicht wird, oder innerhalb eines Prozesses auf ein Ereignis reagiert wird, etwa auf eine 
eingehende Nachricht oder den Ablauf eines bestimmten Zeitraums. 

Gateways können auch ereignisbasiert sein, wenn ein oder mehrere Ereignisse zum 
Durchlaufen von verschiedenen Pfaden führen. Dabei kann die Modellierung mit einem 
ereignisbasierten Gateway erfolgen. 

Die folgende Abbildung (siehe Abb. 3.32) zeigt die Prozessmodellierung eines 
Bewerbungsvorgangs mit Ereignissen. Abhängig davon, ob eine Einladung oder eine 
Absage eintrifft oder eine Deadline von 2 Wochen abläuft, werden unterschiedliche 
Wege im Prozess beschritten. Das ereignisbasierte Gateway ist damit das einzige Gate- 
way, bei dem zum Zeitpunkt der Prüfung des Gateways die dafür notwendigen Daten 
noch nicht vorliegen müssen. Ein ereignisbasiertes Gateway blockiert den Kontrollfluss 
so lange, bis eines der unmittelbar nachgelagerten Ereignisse eintritt und verfolgt dann 
den jeweiligen Zweig weiter. 
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Abb. 3.32 Beispiel für den Einsatz des ereignisgesteuerten Gateways 
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Abb. 3.33 Notationselemente zur Abbildung von Kommunikation in BPMN 


3.5.4 Notationselemente zur Modellierung von Kommunikation 


Die BPMN unterstützt auch die Modellierung verteilter Geschäftsprozesse. Die BPMN 
rückt zwar klar den Prozess bei der Modellierung in den Fokus (wie etwa auch ein 
Flowchart, eine EPK oder ein Aktivitätsdiagramm), aber auch den ausführenden bzw. 
beteiligten Personen eines Prozesses wird Beachtung geschenkt (siehe Abb. 3.33). Die 
dafür zur Verfügung stehenden Modellierungselemente werden in diesem Abschnitt 
betrachtet. 

Ein Pool stellt eine Unternehmung oder eine Organisationseinheit in einer Unter- 
nehmung dar, wie z. B. eine Abteilung. Jede (Swim-)Lane in einem Pool repräsentiert 
eine prozessbeteiligte Person bzw. Rolle, die diesem Pool zugeordnet ist. 

BPMN bietet die Möglichkeit, das Zusammenspiel von zwei oder mehreren Prozes- 
sen aufzuzeichnen. Zur Darstellung von Kollaborationen sind die eben erwähnten Pools 
und Lanes notwendig, wobei für alle an einem Prozess beteiligten Personen oder Grup- 
pen eine eigene Lane erforderlich ist, für jeden Prozess bzw. jede Organisationseinheit, 
die für diesen Prozess verantwortlich ist, ein eigener Pool. In jedem Pool entstehen so 
eigene, individuelle Prozesse mit separaten Start- und Endereignissen. Dennoch kann es 
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vorkommen, dass die einzelnen Prozesse von anderen Prozessen stark beeinflusst wer- 
den. Dies kann durch Nachrichtenflüsse modelliert werden. 

Nachrichtenflüsse geben an, wenn zwischen verschiedenen Prozessen Daten aus- 
getauscht werden. Innerhalb eines Prozesses (Pool) kann daher kein Nachrichtenfluss 
stattfinden. Somit ist kein Nachrichtenfluss innerhalb einer Lane und zwischen einzelnen 
Lanes möglich. Sequenzflüsse zeigen an, welche Aktivitäten in welcher Reihenfolge aus- 
geführt werden. Sie dürfen im Gegensatz zu Nachrichtenflüssen nur innerhalb eines Pool 
stattfinden können und nicht zwischen unterschiedlichen Prozessen (Pools). 

An Nachrichtenflüsse können zusätzlich Nachrichten angebracht werden, die hier 
als Datenelemente eingesetzt werden und eine genauere Spezifikation der übermittelten 
Information enthalten. 

Nachrichtenflüsse dürfen einerseits von Pools und Aktivitäten ausgehen und dort 
enden, andererseits können sie explizit von Sende-Ereignissen abgeschickt und durch 
Empfangs-Ereignisse empfangen werden. Der erstgenannte Fall ist für die beschreibende 
Modellierung von Geschäftsprozessen sinnvoll, bei der ein Kommunikationsvorgang 
zwar erfasst werden soll, aber nicht notwendigerweise exakt beschrieben werden muss. 
Eine von einer Aktivität ausgehende Nachricht wird irgendwann im Zuge der Auf- 
gabenausführung gesendet — der genaue Zeitpunkt bleibt unklar. Eine an einem Pool 
endende Nachricht sagt nur aus, dass die repräsentierte Organisation diese Nachricht 
empfängt, aber nicht, welche Aktivität sie auslöst. Dies kann sinnvoll sein, wenn externe 
Organisationseinheiten modelliert werden sollen, deren detailliertes Verhalten unbekannt 
ist. Nur durch die Verwendung von expliziten Sende- und Empfangsereignissen ist eine 
exakte Spezifikation von Kommunikationsvorgängen möglich. 


3.5.5 Beispiele zur Modellierung von Kommunikation 


Im Folgenden ergänzen wir das Beispiel, das wir zur Demonstration des Einsatzes von 
Ereignissen verwendet haben, um den dort nicht abgebildeten Kommunikationspartner, 
also das Unternehmen, an das eine Bewerbung gerichtet wird. 

Das obenstehende Beispiel (siehe Abb. 3.34) zeigt zwei Prozesse (je einen pro Pool), 
die über Nachrichtenflüsse miteinander verknüpft sind. Der Prozess des Unternehmens 
wird durch eine eingehende Bewerbung gestartet, die hier im ersten Nachrichtenfluss 
abgebildet ist. Nach der Prüfung kann die Entscheidung getroffen werden, ob eine Ein- 
ladung ausgesprochen oder eine Absage erteilt werden soll. Im oberen Pool wartet der 
Bewerber auf eine Antwort — allerdings maximal 2 Wochen lang. Durch das ereignis- 
basierte Gateway wird jener Prozesszweig aktiviert, dessen Ereignis zuerst eintritt. Die 
jeweils zusammengehörigen Sende- und Empfangs-Ereignisse sind über einen Nach- 
richtenfluss gekoppelt. Wichtig ist hier, dass Nachrichtenflüsse immer 1:1-Beziehungen 
abbilden — dass also eine gesendete Nachricht genau einmal empfangen werden kann 
und dass ein empfangendes Ereignis auf genau eine Nachricht reagieren kann. 
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Abb. 3.34 Beispiel von verteilt ablaufenden Prozessen mit Kommunikationsvorgängen 


Das obenstehende Beispiel (siehe Abb. 3.35) zeigt nun, wie die BPMN verwendet 
werden kann, um ausschließlich Kommunikationsvorgänge abzubilden. Die Pools wer- 
den hier als Blackbox verwendet, das in ihnen enthaltene Verhalten ist nicht abgebildet 
und bleibt unbekannt. Wir sehen lediglich, dass Nachrichten ausgetauscht werden, 
wobei die Reihenfolge der Nachrichten nicht definiert ist. Nachdem hier die näher 
beschreibenden Ereignisse zum Versenden und Empfangen fehlen, ergänzen wir das 
Modell um Nachrichten-Elemente, um die Kommunikation nachvollziehen zu können. 
Ein weiterer Unterschied ist der im oberen Pool angebrachte Modifikator, der eine par- 
allele Mehrfachausführung des im oberen Pool enthaltenen Prozesses kennzeichnet. 
Dies bedeutet, dass der Prozess im unteren Pool mit mehreren, parallel unabhängig von- 
einander eintreffenden Bewerbungen umgehen können würde bzw. müsste. 

Leere und gefüllte Pools können auch beliebig kombiniert werden. Wollten wir z. B. 
den Prozess der Bearbeitung einer eingehenden Bewerbung abbilden, könnten wir den 
Pool „BewerberIn“ unspezifisch belassen, da wir deren Verhalten nicht kennen (und es 
auch nicht relevant ist), aber wissen müssen, dass wir von dort eine Bewerbung erhalten 
können und dass wir unsere Antwort dann wieder dorthin adressieren. 
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Abb. 3.35 Ausschließliche Abbildung von Kommunikationsvorgängen in BPMN 


3.5.6 Notationselemente zur Modellierung komplexer 
Sachverhalte 


Die BPMN bietet mithilfe der bislang vorgestellten Notationselemente die Möglich- 
keit, Geschäftsprozesse aus Sicht der durchführenden organisationalen Einheiten darzu- 
stellen. Die BPMN lässt dabei die Freiheit, Prozessmodelle vage zu halten oder Teile 
davon unspezifiziert zu lassen, wenn diese für die Zielsetzung der Modellierung nicht 
relevant erscheinen. In manchen Fällen soll aber ein Prozess möglichst exakt gefasst 
und in all seinen vorstellbaren Varianten und möglicherweise auftretenden Ausnahme- 
fällen abgebildet werden. Dies ist etwa notwendig, wenn das Modell die Grundlage für 
die IT-basierte Unterstützung der abgebildeten Arbeitsprozesse dienen soll. Werden hier 
Aspekte weggelassen oder verkürzt abgebildet, ergibt sich eine Diskrepanz zwischen 
dem realen Arbeitsprozess und den auf dem Modell basierenden Unterstützungsmaßnah- 
men, was letztendlich zu nicht zufrieden stellenden Werkzeugen und Workarounds führt. 
Dieser Abschnitt beschreibt jene Notationselemente der BPMN, die komplexe Ablauf- 
beschreibungen ermöglichen. Aufgrund der Vielfalt der abbildbaren Szenarien führen wir 
Beispiele hier direkt bei der Beschreibung der jeweiligen Elemente an. 


3.5.6.1 Varianten der Aktivitätsmodellierung 
Im folgenden Abschnitt werden Besonderheiten der Modellierung von Aktivitäten sowie 
deren Modellierung als Subprozesse genauer erklärt. 


3.5.6.1.1 Subprozesse 

Prozesse können mittels Subprozessen modelliert werden. Diese Methode wird meistens 
verwendet, um bei der Modellierung von großen, umfangreichen Prozessen den Über- 
blick behalten zu können. Subprozesse können dabei diagrammatisch minimiert werden. 
Dann ist der Prozess nur mehr als kleine Aufgabe im gesamten Prozess zu erkennen und 
durch ein kleines Plus gekennzeichnet. 
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Abb. 3.36 Beispiele für Sub-Prozesse mit parallel (links) oder ad-hoc (rechts) auszuführenden 
Aktivitäten 
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Abb. 3.37 Unterschiedliche Aktivitätstypen 


Subprozesse erlauben aber auch die Zusammenfassung mehrerer Aktivitäten in einen 
Durchführungskontext, ohne deren genaue Reihenfolge festzulegen. Das rechte Modell 
(ein Ad-hoc Unterprozess) in der nachfolgenden Abbildung (siehe Abb. 3.36) gibt nur 
an, dass beliebig viele der eingebetteten Aktivitäten durchgeführt werden können, macht 
aber keine Aussage über deren Zusammenhänge. Das linke Modell legt fest, dass alle 
vier Subaktivitäten ausgeführt werden müssen, bevor der Subprozess abgeschlossen ist. 
Es trifft keine Aussage über die Reihenfolge oder sonstige Zusammenhänge - die Aktivi- 
täten können parallel ausgeführt werden. 


3.5.6.1.2 Aktivitätstypen 

Aufgaben-Typen beschreiben den Charakter einer Aufgabe, also welchen Zweck eine 
Aufgabe erfüllt. Dabei wird unterschieden nach Service, Empfang, Sendung, Benutzer, 
Geschäftsregel, Skript, manuell und unbestimmt (Abbildung von links nach rechts; siehe 
Abb. 3.37). Diese Modifikatoren müssen nicht unbedingt verwendet werden, konkretisie- 
ren aber die Semantik eines Prozessmodells. 


3.5.6.1.3 Ausführungsverhalten von Aktivitäten 

Aktivitäten können unterschiedliche Markierungen haben, die das Ausführungsverhalten 
von Aktivitäten beschreiben. Aktivitäten oder gesamte Prozesse oder Teilprozesse kön- 
nen dabei als Schleife, parallel, sequentiell, ad hoc oder als Kompensation ausgeführt 
werden (siehe Abb. 3.38). 
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Abb. 3.38 Modifikatoren zur Abbildung unterschiedlichen Ausführungsverhaltens 


Bei einer Schleife kann eine Abbruchbedingung zusätzlich zum Symbol angegeben 
werden. Ist die Abbruchbedingung erreicht, wird die Aktivität oder der betreffende 
Prozess nicht mehr länger ausgeführt und die jeweilige übergeordnete Sequenz weiter 
ausgeführt. Kann ein Prozess parallel ausgeführt werden, so wird dies durch drei verti- 
kale Striche gekennzeichnet. So kann beispielsweise der Prozess „Bewerbung prüfen“ 
für mehrere eingelangte Bewerbungsunterlagen von mehreren Bearbeitern durchgeführt 
werden. Ist nur eine parallele Ausführung nicht möglich, die einzelnen Fälle aber 
unabhängig voneinander, so handelt es sich um eine sequenzielle Mehrfachausführung, 
die durch drei horizontale Striche gekennzeichnet wird. 

Bei Ad-Hoc-Prozessen ist die genaue Reihenfolge der enthaltenen Aktivitäten 
unbekannt und ergibt sich erst während der Ausführung des Prozesses. Solche Prozesse 
werden über eine Tilde gekennzeichnet (wie oben bereits dargestellt). Es müssen auch 
nicht alle Aktivitäten abgearbeitet werden. 

Kompensationsaktivitäten werden im Rahmen der Transaktionsmodellierung ver- 
wendet und werden weiter unten beschrieben. 


3.5.6.2 Ereignistypen 
Die BPMN bietet zur detaillierten Ablaufsteuerung eine Vielzahl von unterschiedlichen 
Events in verschiedenen Ausprägungen an. Während wir diese im Folgenden im Detail 
behandeln werden, soll hier ein Überblick gegeben und der systematische Aufbau von 
Events dargestellt werden (siehe Abb. 3.39). 

Grundsätzlich können Events in drei unterschiedlichen Varianten vorkommen, die wir 
oben bereits eingeführt haben: 


e Start-Ereignisse lösen neue Prozessinstanzen aus, starten also die Ausführung eines 
Prozesses. Sie sind immer „empfangend‘“, reagieren also auf Stimuli von außen (etwa 
eingehende Nachrichten, Zeitabläufe etc.). 

e End-Ereignisse sind Ereignisse, die beim Beenden einer Prozessinstanz ausgelöst 
werden. Sie sind immer „sendend“, lösen also potenziell Stimuli für andere Prozesse 
bzw. Prozessteile aus. 

e Zwischen-Ereignisse treten innerhalb des Sequenzflusses auf, haben also sowohl eine ein- 
gehende als auch eine ausgehende Kante (Ausnahme: Link-Event, siehe weiter unten). 
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Abb. 3.39 Vollständiger Satz an BPMN-Ereignis-Typen 


Start-Ereignisse lassen sich darüber hinaus hinsichtlich ihres Einsatzortes unterscheiden. 
Sie können zum Auslösen eines gesamten Prozesses oder zum Auslösen von Sub- 
prozessen verwendet werden. Der zweite Fall wird als „Ereignis-Teilprozess“ bezeichnet 
und kann mittels „unterbrechend‘“ und „nicht-unterbrechend“ spezifiziert werden. Im 
eher üblichen Fall wird durch ein „unterbrechendes“ Startereignis gekennzeichnet, dass 
der Kontrollfluss vollständig an den Subprozess übergeben wird, innerhalb des jewei- 
ligen Pool also alle anderen Aktivitäten unterbrochen werden. „Nicht-unterbrechende“ 
Ereignis-Teilprozesse werden beim Eintreffen des jeweiligen Ereignisses gestartet, ohne 
dass die Durchführung der aktuell innerhalb eines Pool ausgeführten Aktivitäten unter- 
brochen wird. Damit kann etwa auf Ereignisse reagiert werden, die nicht im Haupt- 
prozess eines Pool behandelt werden sollen oder können, deren Auftreten aber eine 
Reaktion nach sich ziehen soll, ohne dass der Hauptprozess beeinträchtigt wird (etwa 
Kundennachfragen über die Status einer Auftragsbearbeitung, während dieser Auftrag 
gerade im Rahmen des Hauptprozesses bearbeitet wird). 
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Zwischenereignisse existieren grundsätzlich in einer „empfangenden“ und einer „sen- 
denden“ Variante. Die „empfangende“ Variante (eingetretenes Ereignis) wartet auf das 
Eintreffen des spezifizierten Ereignisses und blockiert dabei den Sequenzfluss. Die- 
ser kann also nicht fortgesetzt werden, bis das Ereignis eingetreten ist. Die „sendende“ 
Variante (ausgelöstes Ereignis) kennzeichnet das Eintreten bestimmter Ereignisse in 
einem Prozess (oder auch zwischen Prozessen aus unterschiedlichen Pools). Ereignisse 
treten bei vollständig modellierten Prozessen üblicherweise reziprok auf, d.h. dass zu 
einem eingetretenen Event auch ein auslösendes Event existiert. 

Empfangende Zwischenereignisse existieren auch in einer „angehefteten“ Form. 
Diese Ereignisse werden an Aktivitäten „angeheftet“ (d.h. grafisch an deren (Unter-) 
Kante angebracht) und kennzeichnen, dass während der Durchführung der Aktivität 
auf das jeweilige Ereignis reagiert werden können soll. Die Reaktion wird durch einen 
aus dem angehefteten Event ausgehenden Sequenzfluss spezifiziert, der zu den jeweils 
durchzuführenden Aktivitäten führt. Das angeheftete Zwischenereignis existiert dabei 
wiederum in einer unterbrechenden und einer nicht-unterbrechenden Form. Die unter- 
brechende Form bricht die Ausführung der so gekennzeichneten Aktivität ab und setzt 
den Sequenzfluss ausschließlich über das angeheftete Event fort. Die nicht-unter- 
brechende Form erlaubt die weitere Ausführung der so gekennzeichneten Aktivität, par- 
allel dazu wird aber der vom Event ausgehende Sequenzfluss ausgelöst. 

Die auslösenden Ereignisse, die zum Eintreten von angehefteten Events führen, kön- 
nen von außen kommen (etwa von anderen Pools eintreffende Nachrichten) oder auch 
von innerhalb der Aktivität, sofern diese durch einen Subprozess detailliert wird. So 
kann ein Fehler bei der Ausführung des Subprozesses zu Aktivitäten im Hauptprozess 
führen, etwa das Dokumentieren des Fehlers und einer Eskalation zu Vorgesetzten. 

Nachrichten- und Timer-Ereignisse haben wir bereits in der grundlegenden 
BPMN-Modellierung verwendet. Die übrigen Ereignistypen betrachten wir nun im Rah- 
men ihrer jeweiligen Einsatzgebiete. 


3.5.6.3 Das Link-Event 
Bei komplexeren oder umfangreicheren Abläufen wird die Nachverfolgung von 
Sequenzflüssen durch das Diagramm manchmal schwierig. Einander kreuzende 
Sequenzflüsse oder Sequenzflüsse mit vielen Richtungsänderungen erschweren die Les- 
barkeit und sind der Verständlichkeit und Übersichtlichkeit abträglich (siehe Abb. 3.40). 

In derartigen Fällen kann das Link-Event verwendet werden. Im Gegensatz zu den 
übrigen Events bildet es semantisch kein echtes Ereignis ab, sondern dient lediglich als 
Konnektor zwischen zwei Sequenzflüssen, die weit voneinander entfernt liegen. Die 
Kopplung erfolgt dabei über die Bezeichnung des auslösenden und des empfangenden 
Events. Es muss immer eine 1:1-Zuordnung bestehen — eine implizite Parallelisierung 
durch ein auslösendes und mehrere gleichnamige empfangende Link-Events sind folg- 
lich nicht zulässig. 

Link-Events sollten zur Erhöhung der Übersichtlichkeit trotzdem nur in nicht anders 
auflösbaren Fällen genutzt werden, da das Suchen zusammengehöriger Link-Events im 
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Aufwand das Nachverfolgen komplexer Sequenzflüsse sogar übersteigen kann (sofern 
keine Werkzeugunterstützung durch Sprungfunktionalitäten oder optische Markierung 
zusammengehöriger Events besteht). Eine alternative Anordnung von Aktivitäten oder 
Lanes ist üblicherweise die bessere Wahl. 


3.5.6.4 Verwendung von Signalen 

Nachrichten können in BPMN ausschließlich zur Kommunikation zwischen Pools ver- 
wendet werden. Des Weiteren hat eine nachrichtenbasierte Kommunikation immer exakt 
zwei Endpunkte, kann also immer nur genau einen Sender mit genau einem Empfänger 
verbinden. Wenn eine Information global innerhalb einer Kollaboration zur Verfügung 
gestellt werden soll, und dies unabhängig von Poolgrenzen passieren soll, können Sig- 
nale verwendet werden. Signale können (als Zwischen- oder End-Ereignisse) im Prozess 
ausgelöst werden und stehen dann sowohl innerhalb des Pool als auch in allen anderen 
Pools der gleichen Kollaboration zur Verfügung. 

Signale können dazu eingesetzt werden, alle Pools einer Kollaboration etwa über 
den Abbruch eines der abgebildeten Prozesse zu informieren. So können alle anderen 
noch ausgeführten Prozesse für sich ihre Prozesse zum Abschluss bringen und es blei- 
ben keine „Prozessleichen“ zurück, die nicht mehr abgeschlossen werden können, weil 
etwa aufgrund eines Prozessabbruchs eines Kommunikationspartners eine erwartete ein- 
gehende Nachricht nicht mehr ankommt. 


3.5.6.5 Behandlung von Ausnahmen und Unterbrechungen 

Aktivitäten, also Aufgaben und Prozesse, können durch bestimmte Ereignisse 
abgebrochen oder unterbrochen werden. Dies wird durch Ereignissymbole gekenn- 
zeichnet, die der jeweiligen Aktivität angeheftet sind. Wird durch das eintretende 
Ereignis die Aktivität abgebrochen, so wird dies durch zwei durchgehende äußere Kreis- 
linien gekennzeichnet. Wird die Aktivität nicht unterbrochen, so wird dies durch zwei 
gestrichelte Kreislinien dargestellt. Im untenstehenden Beispiel reagieren wir auf das 
Eintreten eines Timer-Ablaufs. Wir können also modellieren, dass die Ausführung der 
Aufgabe nicht länger als eine bestimmte Zeitspanne dauern darf (links) oder dauern 
sollte (rechts), und dass bei Zeitablauf in irgendeiner Form reagiert werden muss. Die 
Reaktion ist in dem vom angehefteten Ereignis ausgehenden Sequenzfluss zu model- 
lieren. Auf dieselbe Art und Weise können auch ungeplante Ereignisse wie Fehler oder 
Eskalationen modelliert und dargestellt werden (siehe Abb. 3.41). 


3.5.6.5.1 Beispiel: Nicht-unterbrechende Timerevents 

Die folgende Abbildung (siehe Abb. 3.42) stellt dar, dass der Teilprozess, der die Aktivi- 
täten der Bearbeitung einer Bestellung in einem Fast Food Restaurant abbildet, nicht län- 
ger als 5 min dauern soll. Dauert die Bearbeitung der Bestellung länger als 5 min, soll 
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Abb. 3.41 Beispiel für angeheftete Ereignisse (links: nicht unterbrechend, rechts: unterbrechend) 
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Abb. 3.42 Beispiel für die Verwendung von nicht-unterbrechenden Timer-Events 
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der Kunde das Geld zurückerhalten. Die Bestellung soll trotzdem noch fertig bearbeitet 
werden. Im Fall eines unterbrechenden Events würde der Kunde lediglich sein Geld 
zurückerhalten, nicht aber das bestellte Essen. 


3.5.6.6 Terminierung von Prozessen 

Sequenzflüsse in einem Prozess werden üblicherweise mit einem Endereignis 
abgeschlossen. Endereignisse beenden jedoch nur die Ausführung des jeweiligen 
Sequenzflusses. Falls parallel noch weitere Sequenzflüsse aktiv sind, etwa, weil sie durch 
eine paralleles oder inklusives Gateway geöffnet wurden oder weil sie durch angeheftete 
Events ausgelöst wurden, werden diese weiterhin ausgeführt. Um einen (Sub-)Prozess 
vollständig und sofort zu beenden (also die Ausführung in allen Zweigen zu beenden), 
existieren mehrere Möglichkeiten. 


3.5.6.6.1 Das Terminate-Event 

Das Terminate-Event bricht alle aktiven Zweige eines Prozesses innerhalb eines Pool 
unmittelbar und sofort ab. Prozesse in anderen Pools sind nicht betroffen und sollten des- 
halb ggf. vor dem Abbruch durch das Senden eines Signals vom Abbruch in Kenntnis 
gesetzt werden. 
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3.5.6.6.2 Das Error-Event 
Das Error-Event zeigt das Auftreten eines semantischen Fehlers an und wird üblicher- 
weise in Subprozessen eingesetzt. Es bricht die Ausführung des Subprozesses ab, der 
Fehlergrund kann dem Event als Parameter mitgegeben werden. Durch angeheftete emp- 
fangende Ereignisse kann auf diese Fehler im übergeordneten Prozess reagiert werden 
und können entsprechende Aktivitäten ausgelöst werden. Angeheftete Fehlerereignisse 
sind immer unterbrechend, brechen also die Ausführung des Subprozesses (inkl. aller 
gegebenenfalls noch aktiver Sequenzflüsse in Zweigen, in denen kein Fehler aufgetreten 
ist) ab. Als „schwächere“ Variante kann auch das „Eskalationsereignis“ in identischer 
Weise verwendet werden. Dieses existiert auch in einer nicht-unterbrechenden Form und 
erlaubt damit die Fortsetzung der Bearbeitung des Subprozesses, in dem das Problem 
aufgetreten ist. 

Falls beim Abbruch von Subprozessen die Auswirkungen von bereits durchgeführten 
Aktivitäten rückgängig gemacht werden müssen, kann auf die im nächsten Abschnitt vor- 
gestellte Transaktionsbehandlung wie in der BPMN vorgesehen zurückgegriffen werden. 


3.5.6.7 Transaktionen 

In BPMN existiert auch die Möglichkeit, Transaktionen in einem Prozess abzubilden. 
Von einer Transaktion spricht man, wenn eine Menge von Aufgaben eines Prozesses als 
Gesamtheit vollständig oder gar nicht ausgeführt werden sollen. Insbesondere sollen bei 
Scheitern einer Aufgabe bestimmte andere bereits abgeschlossenen Aufgaben wieder 
rückgängig gemacht werden. BPMN kennt das Konzept transaktionaler Subprozesse in 
Kombination mit Kompensierungsereignissen und -aktivitäten. Kompensierung bedeutet, 
dass bereits ausgeführte Prozessschritte dadurch zurückgerollt werden, indem konkrete 
Gegenmaßnahmen durch einen weiteren Prozessschritt eingeleitet werden. 

In einem Transaktionssubprozess (in BPMN gekennzeichnet durch eine doppelte 
Umrandung) wird jeder Aufgabe über ein angeheftetes Kompensierungszwischenereig- 
nis (gekennzeichnet durch ein „Zurückspulen“-Symbol) eine Kompensierungsaufgabe 
zugeordnet. Bricht die Transaktion ab, so wird für jede Aufgabe, die bereits erfolgreich 
abgeschlossen wurde, die jeweilige Kompensierung ausgeführt. In diesem Zusammen- 
hang kommt das Abbruch-Event (gekennzeichnet durch ,„X“) ins Spiel. Als auslösendes 
Endereignis in einem Transaktionssubprozess bewirkt es dessen Abbruch und damit 
das Auslösen der Kompensierungen. Wenn es an die Transaktion angeheftet wird, ist es 
ein empfangendes Zwischenereignis und bestimmt es den weiteren Ablauf des Prozes- 
ses nach dem Abbruch der Transaktion. Durch das Konzept der Kompensierung kann 
eine Transaktion auch dann noch zurückgerollt werden, nachdem sie eigentlich schon 
erfolgreich abgeschlossen wurde. Außerhalb der Transaktion kann ein auslösendes 
Kompensierungsereignis verwendet werden, um die Kompensierung der referenzierten 
Transaktion nachträglich auszulösen. 

Die nachfolgende Abbildung (siehe Abb. 3.43) illustriert diese Konzepte anhand eines 
Reisebuchungsprozesses. 
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Abb. 3.43 Beispiel für einen Transaktions-Subprozess 


Eine Reisebuchung besteht aus einer Flug- und einer Hotelbuchung, die potenziell 
parallel vorgenommen werden können. Ist eine der Buchungen nicht möglich, so muss 
die andere Buchung (falls sie schon ausgeführt wurde) wieder storniert werden. Ein Feh- 
ler bei einer einzelnen Buchung löst also den Abbruch der Transaktion aus und führt 
dazu, dass der Prozess mit einer Fehlernachricht an den Kunden reagiert. Außerhalb der 
eigentlichen Transaktion führt ein Fehler bei der Belastung der Kreditkarte zur Stornie- 
rung der gesamten Buchung. 


3.5.6.8 Ereignisgesteuerte Sub-Prozesse 

Ereignisgesteuerte Sub-Prozesse sind eine Alternative zur Behandlung von auftretenden 
Ereignissen in (Sub-)Prozessen. Während an Subprozessen angeheftete Events die 
Reaktion auf diese in den umgebenden Prozess ‚hinaustragen‘, kann diese durch den 
Einsatz von Ereignisgesteuerten Sub-Prozessen lokal gehalten werden. 

Die folgende Abbildung (siehe Abb. 3.44) zeigt ein Beispiel für einen timer-ge- 
steuerten nicht-unterbrechenden Subprozess. Es greift das oben bereits verwendete Sze- 
nario der Zubereitung einer Bestellung in einem Fast-Food-Restaurant wieder auf. 

Die Events, mit denen ereignisgesteuerte Subprozesse ausgelöst werden können, sind 
identisch mit jenen, die an einen Subprozess angeheftet werden können. Beide Varian- 
ten können unterbrechend und nicht-unterbrechend sein. Semantisch unterscheiden 
sie sich wie erwähnt lediglich in der Art der Behandlung des Ereignisses — nämlich 
lokal innerhalb des Subprozesses oder außerhalb im umschließenden Prozess. Je nach 
Anwendungsfall kann die eine oder die andere Variante zu sinnvollen und/oder über- 
sichtlichen Darstellungsformen führen. 
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Abb. 3.44 Beispiel für den Einsatz eines nicht-unterbrechenden ereignisgesteuerten Sub-Prozesses 


3.5.7 Choreografiediagramme 


Die explizite Modellierung von Choreografien in Choreografie-Diagrammen wurde in 
der BPMN 2.0 neu eingeführt. Bei einer Choreografie handelt es sich um den Ablauf 
von Nachrichtenaustauschen zwischen unterschiedlichen Akteuren. Eine Choreografie ist 
damit eine andere Sicht auf eine Kollaboration, bei der die Reihenfolge der Nachrichten- 
übermittlung unabhängig von den Prozessen der einzelnen Akteure dargestellt wird. 

Zwar kann man einer Darstellung der Kommunikation mittels zugeklappten, d. h. 
leeren, Pools entnehmen, welche Nachrichten zwischen welchen Partnern ausgetauscht 
werden, doch lassen sich die genaue Reihenfolge, bedingte Nachrichtenflüsse oder 
Schleifen nicht daraus ersehen. So ist im bislang verwendeten Bewerbungsbeispiel bei- 
spielsweise nicht gezeigt, dass nach dem Eintreffen eines Angebots beim Kunden ent- 
weder die Einladungs- oder die Absage-Nachricht gesendet wird. Dies lässt sich mit 
einem Choreografie-Diagramm visualisieren. 

Die folgende Abbildung (siehe Abb. 3.45) enthält die Choreographie zu dem oben 
bereits als Kollaboration gezeigten Beispiel eines Bewerbungsprozesses. Hier sind die 
Nachrichtenaustauschvorgänge in den Mittelpunkt gerückt. Eine sogenannte Choreo- 
graphie-Aktivität (Choreography Activity) repräsentiert den Austausch einer oder meh- 
rerer Nachrichten zwischen zwei oder mehreren Partnern. Im einfachsten Fall entspricht 
sie dem Senden einer einzigen Nachricht von einem Partner zu einem anderen. 

Jede Choreografie-Aktivität wird von einem der beteiligten Partner ausgelöst, indem 
er die erste Nachricht sendet. Dieser auslösende Partner wird am oberen oder unteren 
Rand der Choreografie-Aktivität in einem hellen Feld eingetragen. Die Namen des oder 
der weiteren Beteiligten werden am anderen Rand in einem dunkleren Feld eingetragen. 
Wer oben und wer unten eingetragen wird, ist dem Modellierer freigestellt. Normaler- 
weise wird man bei mehreren Choreografie-Aktivitäten zwischen denselben Partnern die 
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Anordnung beibehalten. Wenn man zusätzlich noch eine Kollaboration modelliert, ist es 
naheliegend, die vertikale Anordnung der Pools zugrunde zu legen. Entsprechend sind in 
den Choreografie-Aktivitäten der Abbildung entweder der Kunde oben und die Werbe- 
agentur unten oder aber die Werbeagentur oben und die Grafiker unten eingezeichnet. 

Choreografie-Aktivitäten mit mehr als zwei Partnern kommen in diesem Beispiel 
nicht vor. Hierfür kann man oben bzw. unten mehrere Partner-Felder eintragen. Dabei 
ist aber immer nur ein Feld hell hinterlegt, da nur einer der Partner den Nachrichtenaus- 
tausch durch eine initiale Nachricht in Gang setzen kann. 

Für die Choreografie-Aktivitäten ist im Choreografie-Diagramm ein Sequenzfluss 
definiert. Seine Modellierung entspricht im Wesentlichen der Sequenzfluss-Modellierung 
von Prozessen. Allerdings sind gewisse Elemente der Prozessmodellierung im 
Zusammenhang mit der Choreografie-Modellierung nicht sinnvoll und daher auch nicht 
zulässig. So gibt es z. B. keine Nachrichten- Ereignisse innerhalb eines Sequenzflusses, 
da der Nachrichtenaustausch per Definition Teil der Choreografie-Aktivitäten ist. Ent- 
sprechend folgen beispielsweise auf das ereignisbasierte Gateway in der Abbildung keine 
Ereignisse, sondern Choreografie-Aktivitäten. Hierbei wird der Pfad gewählt, dessen 
Choreografie-Aktivität als erste durch die jeweilige auslösende Nachricht gestartet wird. 

Will man wissen, welche Nachrichten in jeder Choreografie-Aktivität ausgetauscht 
werden, so können diese wiederum in Form kleiner Briefsymbole hinzugefügt und mit 
dem jeweiligen Partnerfeld verbunden werden. Die Briefe sind ebenso wie die beteiligten 
Partner farblich gekennzeichnet. Ein helles Briefsymbol steht für die Nachricht, mit der 
eine Choreografie-Aktivität ausgelöst wird. Die Briefsymbole der anderen Nachrichten 
sind dunkler dargestellt. 


3.5.8 Einordnung 


Die BPMN hat sich in den letzten Jahren auch in der industriellen Praxis durch- 
gesetzt. Durch ihren umfassenden Satz an Sprachelementen eignet sie sich für viele 
Anwendungsbereiche von der Dokumentation bis hin zur automationsgestützten Aus- 
führung von Geschäftsprozessen in Organisationen. Der umfangreiche Sprachschatz 


114 3 Modellierungssprachen 


wird gleichzeitig aufgrund der gesteigerten Komplexität als Manko der BPMN gesehen. 
Insbesondere die Vielzahl an Ereignistypen mit zum Teil nur schwer zu unterscheidenden 
Bedeutungen führt zu gesteigertem Aufwand beim Erlernen der Sprache. 

Der mit der möglichen Komplexität der entstehenden Modelle und der damit ein- 
hergehenden erschwerten Verständlichkeit wird üblicherweise dadurch begegnet, dass 
in geeigneten Anwendungsfällen ein reduzierter Sprachumfang verwendet wird. Zur 
deskriptiven Dokumentation von Geschäftsprozessen ist es üblicherweise nicht not- 
wendig, den vollständigen Satz an Ereignissen und komplexeren Aufgabentypen zu 
verwenden. Erst wenn ein Prozessmodell etwa durch Simulation validiert oder zur Aus- 
führung gebracht werden soll, müssen die Modelle um Information zu Ausnahmefällen 
o.Ä. angereichert werden. In diesen Fällen kann von den einfacheren Modellen aus- 
gehend eine Detaillierung und Ergänzung vorgenommen werden. 

Die BPMN ist eine der wenigen Sprachen zur Geschäftsprozessmodellierung, die 
explizit auf Kommunikationsvorgänge zwischen beteiligten Akteuren eingeht und deren 
Abbildung ermöglicht. Bei der Definition der Sprache war der Ausgangspunkt zur Spezi- 
fikation von Kommunikationsflüssen allerdings die Kopplung technisch getrennter 
Informationssysteme. Die BPMN geht implizit davon aus, dass es innerhalb eines Pool 
(also zwischen Lanes) nicht notwendig ist, sich um die Kommunikation zwischen Akteu- 
ren zu kümmern, weil alle Zugriff auf die gleiche Informationsinfrastruktur haben. Zwi- 
schen Pools werden Nachrichtenflüsse modelliert, die im Rahmen der Ausführung dazu 
dienen, die Abbildung der im Ausgangspool verwendeten Datenstrukturen auf jene des 
Ziel-Pool zu beschreiben. 

Ein Nachrichtenfluss entspricht also im Wesentlichen semantisch einer Daten- 
übergabe von einem Informationssystem zu einem anderen und ist dem entsprechend 
immer ein Kommunikationsvorgang mit genau einem Sender und genau einem Emp- 
fänger — mehrere Empfänger können beispielsweise nicht mit einer einzelnen Nach- 
richt angesprochen werden. Während dieser Mechanismus auch zur Abbildung von 
nicht-technischer Kommunikation eingesetzt werden kann, ist seine Ausdrucksstärke 
jedoch beschränkt. Insbesondere kann etwa eine Kommunikation zwischen zwei oder 
mehreren Akteuren ohne klar abgrenzbare Nachrichten nur auf Umwegen und mehr- 
deutig modelliert werden. Diese Einschränkung ist jedoch dem Anspruch der Ausführ- 
barkeit der erstellen Prozesse geschuldet und existiert in dieser Form auch in anderen 
kommunikationsorientierten Ansätzen. 

Die BPMN fokussiert des Weiteren auf Prozessen mit einem vollständig spezifizier- 
baren Kontrollfluss. Dies stößt an Grenzen, sobald Prozessteile fallspezifisch und nicht 
vorab im Detail beschreibbar sind. Für derartige Prozesse haben sich in den letzten Jah- 
ren unterschiedliche Ansätze gebildet, die entweder auf eine deklarative Modellierung 
der Ausführungsbedingungen von Prozessteilen abzielen, oder die Kommunikations- 
vorgänge zwischen den beteiligten Akteuren in den Mittelpunkt stellen. Als Beispiel für 
letztere Kategorie betrachten wir im nächsten Abschnitt die subjektorientierte Geschäfts- 
prozessmodellierung (S-BPM). 
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3.6 S-BPM 


Ein subjektorientiertes Prozessmodell beschreibt im Gegensatz zu anderen 
Modellierungsansätzen Geschäftsvorgänge primär aus Sicht von miteinander kom- 
munizierenden Handelnden oder Systemen. Es erfasst, welche Arbeitsschritte eines 
Geschäftsprozesses durch wen bzw. welches System mit welchen Hilfsmitteln ausgeführt 
werden, welches Ergebnis dadurch erzeugt wird und für wen dieses bestimmt ist. 

Bei der Modellierung nach dem subjektorientierten Ansatz stehen die Subjekte als 
Repräsentanten für an einem Prozess beteiligte Handelnde bzw. ausführende Systeme 
im Mittelpunkt der Betrachtung. Es wird im Wesentlichen beschrieben, wer in welcher 
Form miteinander kommuniziert und wie die einzelnen Akteure auf erhaltene Nach- 
richten reagieren. Die Beschreibung der Kommunikation erfolgt durch die Definition 
der Nachrichten, die zwischen den Subjekten ausgetauscht werden. Das Verhalten der 
Subjekte wird jeweils separat durch Zustandsdiagramme beschrieben, wobei drei unter- 
schiedlichen Zustandstypen zum Einsatz kommen: Ein Subjekt kann auf eine Nachricht 
warten, eine Nachricht senden oder etwas tun, ohne mit anderen Subjekten zu kommu- 
nizieren. Der letztere Zustandstyp wird als Funktionszustand bezeichnet und wird ver- 
wendet, um das eigentliche Verhalten, also die Aktivitäten eines Subjekts zu beschreiben. 


3.6.1 Notationselemente 


Bei der Modellierung nach dem subjektorientierten Ansatz stehen die Subjekte als 
Repräsentanten für an einem Prozess beteiligte Handelnde bzw. ausführende Systeme 
im Mittelpunkt der Betrachtung. Die Modellierung eines Prozesses läuft im Wesent- 
lichen in folgenden Schritten mit zunehmendem Detaillierungsgrad ab: zuerst wird das 
Interaktionsdiagramm erstellt, in dem die Subjekte und deren Nachrichtenaustausch 
modelliert werden (siehe Abb. 3.46). In einem weiteren Schritt wird das Verhalten jedes 
Subjektes in einem separaten Verhaltensdiagramm beschrieben. 

Für das Interaktionsdiagramm werden zuerst die an einem Prozess beteiligten Sub- 
jekte festgelegt. Ein Subjekt ist eine aktive Einheit, muss aber nicht unbedingt ein 
menschlicher Akteur sein. Auch technische Systeme können Subjekte sein, solange sie 
eine aktive Rolle im Prozess einnehmen. Subjekte sind immer abstrakt zu beschreiben, 
d. h. nicht für konkrete Personen oder Maschinen, sondern auf Basis der notwendigen zu 
erfüllenden Aufgaben im Prozess festzulegen (also etwa „Antragsprüfer“, und nicht „Hr. 
Müller“). 


Abb. 3.46 Notationselemente Subjekt 
des S-BPM 
Interaktionsdiagramms 


— 


Nachricht 
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Abb. 3.47 Notationselemente des S-BPM Verhaltensdiagramms 


Zwischen den Subjekten werden Nachrichten ausgetauscht. Im Interaktionsdiagramm 
wird nur festgelegt, welche Nachrichten existieren und wer jeweils Sender und Empfän- 
ger ist. Die Reihenfolge der Nachrichten wird hier noch nicht festgelegt (siehe Abb. 3.47). 

Für jedes Subjekt wird im Verhaltensdiagramm beschrieben, in welcher Reihen- 
folge es Nachrichten sendet und empfängt bzw. interne Funktionen ausführt. Die einzel- 
nen Zustände werden mit Verbindungen zueinander in Beziehung gesetzt, welche die 
Zustandsübergänge beschreiben. Deren Verwendung hängt vom jeweils eingesetzten 
Zustandstyp ab: 


e Zu jedem Funktionszustand wird beschrieben, was im jeweiligen Verhaltensschritt zu tun 
ist. Die Endbedingungen eines Funktionszustandes entsprechen den ausgehenden Ver- 
bindungen, die vom jeweiligen Funktionszustand ausgehen. Wenn die Funktion zu unter- 
schiedlichen Ergebnissen führen kann, können also verschiedene Folgezustände aktiviert 
werden. Dadurch wird die Abbildung von alternativen Verhaltensweisen möglich. 

e In einem Sendezustand wird eine Nachricht an einen Empfänger übermittelt. In ihm 
wird so lange verharrt, bis der Empfänger in der Lage ist, die Nachricht entgegenzu- 
nehmen. Wer die Nachricht empfangen soll und welche Nachricht übermittelt wird, 
wird an der ausgehenden Kante des Sendezustands beschrieben. 

e In einem Empfangszustand wird so lange verharrt, bis eine der Nachrichten ein- 
getroffen ist, die der Empfangszustand entgegennehmen kann. Da auf unterschied- 
liche Nachrichten reagiert werden kann, kann je nach Typ der eingetroffenen 
Nachricht auch ein unterschiedlicher Folgezustand aktiviert werden. Dazu werden 
wiederum mehrere ausgehende Verbindungen verwendet, an denen beschrieben wird, 
welche Nachricht von welchem Absender zum entsprechenden Zustandsübergang 
führt. Auf diese Weise wäre es auch möglich, auf die gleiche Nachricht von unter- 
schiedlichen Absendern unterschiedlich zu reagieren. 


3.6.2 Beispiele 


Um die Unterschiede und Gemeinsamkeiten zu den zuvor diskutierten Modellierungs- 
sprachen herauszuarbeiten, bedienen wir uns hier wieder der bereits verwendeten Bei- 
spiele. In den ersten Beispielen findet keine Kommunikation statt, wir fokussieren 
deshalb auf das Verhaltensdiagramm des jeweils einzigen beteiligten Subjektes. 

Dieses Beispiel (siehe Abb. 3.48) zeigt einen Prozess mit einer einzelnen Aufgabe, in 
der ein Antrag (über den wir hier nicht mehr wissen) bearbeitet wird. Der Prozess endet, 
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Abb. 3.48 Einfacher 
Prozess als S-BPM 
Verhaltensdiagramm 


[Prüfung 
abgeschlossen] 


nachdem die Bearbeitung des Antrags abschlossen wurde. Ein Verhaltensdiagramm muss 
immer einen Startzustand haben, der üblicherweise durch ein Dreieck in der linken obe- 
ren Ecke gekennzeichnet wird. Außerdem muss ein Endzustand existieren, der durch ein 
Dreieck in der rechten unteren Ecke gekennzeichnet wird. Um das Verhalten des Subjek- 
tes vollständig zu beschreiben, benötigen wir einen Zustandsübergang, der kennzeichnet, 
unter welchen Bedingungen wird den Zustand „Antrag prüfen“ verlassen können. Des- 
halb fügen wir hier einen funktionslosen Zustand „Fertig“ ein, den wir als Endzustand 
kennzeichnen. 

Im obenstehenden Beispiel (siehe Abb. 3.49) ist der Prozess um eine Entscheidung 
mit drei möglichen Ausgängen erweitert, die einander ausschließen. Der Antrag wird 
geprüft, das Ergebnis dieser Prüfung ermöglicht das Treffen einer Entscheidung über die 
weitere Bearbeitung. Im Falle einer Investitionssumme ab 10.000 EUR wird der Antrag 
weitergeleitet. Dies kennzeichnen wir durch einen Sendezustand und spezifizieren an der 
ausgehenden Verbindung, wer den Antrag erhalten soll. Damit der Prozess vollständig 
beschrieben ist, müsste an dieser Stelle auch ein Verhaltensdiagramm für den Vor- 
gesetzten erstellt werden. 


[Investition < 1000 EUR] i & [Investition > 9999 EUR] 
Antrag ] 
prüfen 

[Investition 
> 999 EUR& 
<10000 EUR] | 
t ` t í t 
t 5 Antrag 
Antrag Beilagen weiterleiten 
bestätigen prüfen x 7 
[Prüfung [Prüfung [an Vorgesetzter: 
abgeschlossen] abgeschlossen) Antrag] 


[24 


Abb. 3.49 S-BPM Verhaltensdiagramm mit Verzweigung (3 Zweige) 
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Auch hier können wir Teile eines Prozesses wiederholt abarbeiten (siehe Abb. 3.50). 
Dazu wird eine Verbindung am Ende des zu wiederholenden Teils eingefügt, mit einer 
Wiederholungsbedingung versehen und zum ersten Zustand des zu wiederholenden Teils 
zurückgeführt. Die andere ausgehende Verbindung führt den Prozess nach der wieder- 
holten Abarbeitung weiter. 

Das obige Beispiel zeigt nun einen Prozess mit zwei Subjekten. Die erste Abbildung 
(siehe Abb. 3.51) zeigt das Interaktionsdiagramm. Die beiden folgenden Modelle (siehe 
Abb. 3.52) zeigen die Verhaltensdiagramme von Sachbearbeiter und Abteilungsleiter. 
Die positive oder negative Beurteilung wird jeweils als Nachricht übermittelt. Die 
Begründung zur Beurteilung wird nur im Falle einer negativen Beurteilung als Daten- 
objekt zur Aufgabe „Antrag ablehnen“ übergeben. Im Fall der Bestätigung des Antrags 
wird das Datenobjekt „Beurteilung“ nicht mehr benötigt — wir können also annehmen, 
dass in diesem Fall keine weitere Begründung erfolgt. 


3.6.3 Erweiterte Formen der Kommunikationsmodellierung 


Durch den Fokus von S-BPM auf die Abbildung von Kommunikationsvorgängen erlaubt 
diese eine umfassendere und flexiblere Beschreibung derselben als sämtliche zuvor 
betrachteten Modellierungssprachen. Insbesondere erlaubt die S-BPM die Abbildung 


[Weitere Anträge 
vorhanden] 


[Keine weiteren 
Anträge vorhanden] 


& 
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Abb. 3.50 S-BPM Verhaltensdiagramm mit Schleife 


Abb. 3.51 S-BPM Sachbearbeiterin Abteilungsleiterln 
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Abb.3.52 S-BPM Verhaltensdiagramme zum obigen Interaktionsdiagramm (links: Verhalten 
Sachbearbeiter, rechts: Verhalten Abteilungsleiter) 


von komplexen Kommunikationsszenarien durch den Einsatz von Inputpools sowie die 
detaillierte Beschreibung der in Nachrichten ausgetauschten Daten durch Geschäfts- 
objekte — wie nachfolgend erklärt. 


3.6.3.1 Inputpools 

Ein Inputpool dient einem Subjekt quasi als Postkasten, in dem eingehende Nachrichten 
gespeichert werden, bis sie im Verhaltensdiagramm benötigt werden. Im Gegensatz zu 
einem einfachen Postkasten ist ein Inputpool aber konfigurierbar. Es kann festgelegt 
werden, wie viele Nachrichten welchen Typs zwischengespeichert werden können. 
Wenn der Inputpool entsprechend seiner Konfiguration nicht in der Lage ist, eine Nach- 
richt entgegenzunehmen, so muss der Sender im Sendezustand warten, bis die Nachricht 
zugestellt werden kann. Dadurch lassen sich unterschiedliche Kommunikationsszenarien 
abbilden. 

Wird der Platz im Inputpool für einen bestimmten Nachrichtentyp auf 0 reduziert, so 
muss der Sender immer warten, bis der Empfänger bereit ist, die Nachricht entgegenzu- 
nehmen. Man spricht dann von synchroner Kommunikation. Wenn der Inputpool so kon- 
figuriert ist, dass er Nachrichten zwischenspeichern kann, muss der Sender nicht warten, 
bis der Empfänger in jenem Zustand ist, in dem er die Nachricht annehmen kann. Man 
spricht dann von asynchroner Kommunikation (dies ist die einzige Art der Kommunika- 
tion, die in der BPMN abgebildet werden kann). Darüber hinaus erlauben Inputpools, 
Nachrichten in beliebiger Reihenfolge entgegen zu nehmen. Die Nachrichten müssen 
also nicht in jener Reihenfolge abgearbeitet werden, in der sie eintreffen, sondern kön- 
nen entsprechend der Bedürfnisse des Empfängers verarbeitet werden. 

Inputpools haben keine grafische Entsprechung in der S-BPM, sondern sind ein Kon- 
zept der Ausführungssemantik. Sie werden für jedes Subjekt textuell bzw. in einem 
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Konfigurationswerkzeug beschrieben. Wenn keine Inputpools definiert werden, so hat 
die Standardkonfiguration unbegrenzt viele Speicherstellen für beliebige Nachrichten. 
Das Kommunikationsverhalten entspricht also den Nachrichtenflüssen der BPMN (asyn- 
chrone Kommunikation). 


3.6.3.2 Geschäftsobjekte 

Geschäftsobjekte dienen der Spezifikation jener Dinge, die zur Leistungserbringung 
in einem Geschäftsprozess benötigt werden. Es sind also die Dinge, die in einem Pro- 
zess verwendet werden und können Daten genauso umfassen wie physische Ressour- 
cen. Geschäftsobjekte sind passiv, d. h. sie initiieren keine Interaktionen oder Aktionen. 
Geschäftsobjekte werden von Subjekten bearbeitet und können Nachrichten zugeordnet 
werden, um diese hinsichtlich ihres Inhalts näher zu spezifizieren. 

Wie für Inputpools gibt es auch für Geschäftsobjekte keine grafische Entsprechung in 
der Notation der Modellierungssprache und sind ebenfalls Konzepte der Ausführungs- 
semantik und daher von der technischen Ausführungsumgebung abhängig. Sie werden 
deshalb üblicherweise tabellarisch angegeben. Eine Grundstruktur von Geschäftsobjekten 
besteht aus einem Bezeichner, aus Datenstrukturen und Datenelementen. Der Bezeichner 
eines Geschäftsobjektes ergibt sich aus dem Geschäftsumfeld, in dem es eingesetzt wird. 
Beispiele sind Dienstreiseantrag, Bestellung, Lieferschein, Rechnung etc. 

Geschäftsobjekte setzen sich aus Datenstrukturen zusammen, deren Komponen- 
ten einfache Datenelemente eines bestimmten Typs (z. B. Zeichenkette oder Zahl) oder 
selbst wieder Datenstrukturen sein können. 

Um das Verständnis sicherzustellen bzw. zu erleichtern empfiehlt es sich, die 
Bedeutung der Datenelemente näher zu beschreiben, insbesondere dann, wenn sich diese 
nicht zweifelsfrei aus den Bezeichnern ableiten lässt. 

Die folgende Abbildung (siehe Tab. 3.1) zeigt ein Beispiel für einen Dienstreise- 
antrag. Dieser besteht unter anderem aus der Datenstruktur ‚Daten zum Antragsteller‘ 
(Mitarbeiter) mit den Datenelementen für Name, Vorname und Personalnummer und der 
Struktur „Daten zur Dienstreise“ mit den Datenelementen für Beginn, Ende und Zweck 
der Reise. 

In vielen Fällen ändert sich die Semantik eines Geschäftsobjekts während der 
Prozessausführung, etwa wenn ein Lieferschein in eine Rechnung überführt wird. Für 
ein Geschäftsobjekt können deshalb mehrere verschiedene Zustände definiert werden. 
Bei einem Wechsel des Status werden nur die Datenstrukturen bzw. Datenelemente des 
vorherigen Status übernommen, die der neue Status benötigt, und bei Bedarf neue Kom- 
ponenten hinzugefügt oder nicht mehr benötigte entfernt. Damit ist gewährleistet, dass 
ein Subjekt nur diejenigen Datenelemente für seine Arbeit zur Verfügung bekommt, 
die es dafür wirklich benötigt. Dies erleichtert die Einhaltung von Datenschutz- 
bestimmungen. 

Im Beispiel des Dienstreiseantrags kann aus dem ursprünglichen Status „Reiseantrag“ 
des Geschäftsobjekts der Status „Dienstreisebuchung“ abgeleitet werden. Dabei werden 
insbesondere Datenelemente mit internen Angaben wie Personalnummer, Vergütungs- 
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Tab. 3.1 Datenstruktur des Geschäftsobjekts ‚DR-Antrag‘ (Dienstreiseantrag) 


Datenstruktur Bedeutung Datentyp | Kann/Muss | Wertebereich/Default 

Daten zum Antragsteller 

Name Nachname Character |M 

Vorname Vorname Character |M 

Personalnummer en Integer M 

Organisationseinheit K 

Vergütungsgruppe K 

Daten zur Reise 

Reisebeginn Ben Date M innerhalb/Jahres ab akt. 
Datum/akt. Datum 

Reiseende Br Date M Reisebeginn plus/Jahr/ 
Reisebeginn 

Internationale Reise er Boolean |K j/n; n 

Reiseziel (Ort/Land) S Character | M 

Reisegrund ae Character | M 

Gewünschter Vor- BR Integer K 

schuss 

Daten zur Genehmigung 

Genehmigung Genehmigungs- | Boolean |M j/n; n 

vermerk 

Kostenstelle S Integer M 

Gewünschter Vor- aE Integer K 

schuss 


gruppe, Reisegrund und die komplette Datenstruktur zur Genehmigung entfernt, welche 
beispielsweise bei der Einschaltung eines Reiseagenten für die Buchung das Unter- 
nehmen nicht verlassen sollen und auch nicht außerhalb relevant sind. Dafür wird, wie 
in der folgenden Abbildung (siehe Tab. 3.2) gezeigt, eine neue Datenstruktur „Daten zur 
Buchung“ eingefügt. Sie enthält Datenelemente, mit denen die Reisestelle gegenüber 
dem Reiseagenten eine Frist für den spätesten Eingang der Buchungsbestätigung setzen 
und bestimmte Hotelketten vorgeben kann, mit denen beispielsweise Rahmenverträge 
bestehen. 


3.6.4 Einordnung 


Im Gegensatz zu den anderen bislang besprochenen Modellierungssprachen gibt es in 
der S-BPM kein einzelnes Diagramm, das einen Geschäftsprozess vollständig beschreibt. 
Vielmehr wird für jedes Subjekt ein separates Verhaltensdiagramm erstellt. Diese werden 
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Tab. 3.2 Geschäftsobjekt ‚DR-Antrag‘ im Status ‚Dienstreisebuchung‘ 


Datenstruktur/ Bedeutung Datentyp | Kann/Muss | Wertebereich/Default 
Datenelement 


Daten zum Antragsteller 
Name Nachname Character |M | PER 


Vorname Vorname Character |M 


Daten zur Reise 


Reisebeginn Bu: Date M innerhalb/Jahres ab 
akt. Datum/akt. Datum 

Reiseende u Date M Reisebeginn plus/Jahr/ 
Reisebeginn 

Reiseziel (Ort/Land) |... Character | M 


Daten zur Buchung 


Vertragshotelketten | Genehmigungs-vermerk | Character | M 


Frist für Buchungs- |... Date K 
bestätigung 
Buchungsbestätigung |... Date M yn 


durch ein Interaktionsdiagramm miteinander verknüpft, in dem ihr Nachrichtenaustausch 
beschrieben ist. Dadurch ermöglicht S-BPM eine lose Kopplung von Prozessteilen 
und eine einfachere Veränderbarkeit des Verhaltens eines Subjektes, solange dessen 
Kommunikationsschnittstelle, also der Satz an empfangenen und gesendeten Nachrichten 
und deren Reihenfolge, unverändert bleibt. 

Die Verwendung von Zustandsdiagrammen zur Beschreibung des Verhaltens eines 
Subjekts stellt ebenfalls einen grundlegenden Unterschied zu den anderen bislang 
behandelten Sprachen dar. Ein Zustandsdiagramm beschreibt — wie im Namen bereits 
enthalten — den Zustand eines Systems (hier: eines Subjektes — dies kann genauso ein 
Mensch wie eine Maschine sein) und die Ereignisse, die zu einem Zustandsübergang 
führen. Ein Subjekt kann sich immer nur in genau einem Zustand befinden - es ist des- 
halb per Definition nicht in der Lage, Vorgänge parallel auszuführen. Vielmehr arbei- 
ten alle Subjekte parallel und unabhängig voneinander. Dies bedingt ein Umdenken 
bei der Modellierung, da Konstrukte wie UND-Konnektoren (in EPKs), Split/Joins (in 
Aktivitätsdiagrammen) oder parallele Gateways (in BPMN) nicht zur Verfügung stehen. 
Gleichzeitig führt dieser Modellierungsansatz zu einfacheren, kompakteren Modellen 
und einem vor allem im Gegensatz zur BPMN deutlich reduzierten Sprachumfang, was 
der Verständlichkeit der Modelle zuträglich ist. 
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3.7 Vergleich und Gegenüberstellung 


Die hier betrachteten Modellierungssprachen sind unterschiedlich ausdrucksstark und 
haben aufgrund ihrer historischen Entwicklung unterschiedliche Schwerpunkte in der 
Abbildung von Aspekten der Geschäftsprozessmodellierung. Dieser Abschnitt ver- 
sucht, diese Unterschiede nochmals systematisch anhand der im letzten Kapitel vor- 
gestellten Prozessdefinition darzustellen und so die Handhabbarkeit der Sprachen ihrer 
Ausdrucksstärke gegenüberzustellen. Dabei ziehen wir die Semantik der vorgestellten 
Modellierungselemente als Ausgangspunkt heran. 

Der Referenzpunkt der folgenden Betrachtungen ist die Prozessdefinition aus dem 
letzten Kapitel, die wir hier der Einfachheit halber nochmals anführen: 


1. Prozessstrategie: Prozesse haben 
a) einen definierten Anfang und Input (Startereignis), 
b) und weisen ein definiertes Ende mit einem Ergebnis auf, 
c) zur Befriedigung eines Kundenbedürfnisses (und damit zur Wertschöpfung beizu- 
tragen), 
2. Prozesslogik: Ein Prozess 
a) ist die Summe von miteinander verknüpften Aktivitäten (Aufgaben), 
b) die nach dem Startereignis von Handelnden 
c) in sachlogischer und zeitlicher Reihenfolge 
d) zur Bearbeitung eines Geschäftsobjekts ausgeführt werden um 
e) das gewünschte Ergebnis zu erzeugen. 
3. Prozessrealisierung: Ein Prozess wird realisiert 
a) In dem Menschen und/oder Maschinen die Aufgaben der jeweiligen Handelnden 
übernehmen, und diese 
b) mit Hilfsmitteln (Sachmittel, Information, Anwendungsprogramme etc.) ausführen 


Auf Basis dieser Definition können die Konzepte identifiziert werden, die in einem 
Prozessmodell abbildbar sein müssen, um Prozesse vollständig (entsprechend obiger Defi- 
nition) abbilden zu können. Die folgende Tabelle (siehe Tab. 3.3) zeigt diese Konzepte. 
Mehrfach vorkommende Konzepte werden nur beim erstmaligen Auftreten genannt — 
wie z. B. „Ergebnis“. Bei Konzepten, die unterschiedlich konkret angeführt sind, werden 
nur die konkreteren Konzepte betrachtet — z. B. „miteinander verknüpfte Aktivitäten“ als 
allgemeinere Formulierung von „sachlogische und zeitliche Reihenfolge“. 

Ordnet man nun die Modellierungselemente der betrachteten Sprachen diesen Kon- 
zepten zu, so ergibt sich folgende Tabelle (siehe Tab. 3.4): 

Zu erkennen ist, dass die konzeptionelle Abdeckung über die Sprachen hinweg vari- 
iert. Darüber hinaus zeigt sich, dass nicht alle Sprachen alle Konzepte in gleichem 
Umfang bzw. in der der gleichen Ausdrucksstärke behandeln. Die Zuordnung der 
Modellierungselemente zu den Konzepten ermöglicht einen ersten Ansatzpunkt für die 
Einschätzung ihrer Ausdrucksstärke. 


124 3 Modellierungssprachen 


Tab. 3.3 Konzepte der Definitionsteil Konzept 
Geschäftsprozessdefinition la Anlatg 
Input 
1b Ende 
Ergebnis 
lc Kundenbedürfnis 
2a Aktivitäten/Aufgaben 
2b Startereignis 
Handelnder 
2c Sachlogische Reihenfolge 
Zeitliche Reihenfolge 
2d Geschäftsobjekt 
3a Mensch 
Maschine 
3b Sachmittel 
Information 
Anwendungsprogramm 
Hilfsmittel (allgemein) 


Nur bedingt erkennbar werden in dieser Übersicht die unterschiedlichen Zugänge 
in der Abbildung der sachlogischen und zeitlichen Zusammenhänge. Dennoch unter- 
scheiden sich in diesem Punkt die Sprachen wesentlich: Flowcharts bieten keine 
Möglichkeit zur Abbildung paralleler Abläufe, in EPKs ist lediglich eine starke Kopp- 
lung von parallel verlaufenden Aktivitätszweigen vorgesehen, indem diese innerhalb 
eines Prozesses mittels UND- bzw. ODER-Operator verknüpft werden. UML Aktivi- 
tätsdiagramme und BPMN bieten die gleichen Mechanismen (unter anderen Namen), 
erlauben aber auch eine lose Kopplung von Prozessen bzw. Prozessteilen mittels Signa- 
len (bei Aktivitätsdiagrammen) bzw. Nachrichtenflüssen (bei BPMN). 

Insbesondere letzterer Mechanismus ermöglicht eine detaillierte Beschreibung von 
Kommunikationsabläufen von grundsätzlich unabhängigen Prozessteilen. Eine Ein- 
schränkung liegt in der notwendigen Vorabfestlegung von eindeutigen Zuordnungen 
zwischen Sendern und Empfängern von Nachrichten. Die S-BPM bietet einen ähnlichen 
Kommunikationsmechanismus, ist aber in diesem Punkt flexibler (insbesondere bei Ver- 
wendung der in der grafischen Darstellung der Sprache nicht abgebildeten Inputpools). 
Eine Beschreibung von parallel ablaufenden Prozessteilen ist in der S-BPM nur durch 
die Verteilung derselben auf unterschiedliche Subjekte möglich — innerhalb eines Sub- 
jektes kann immer nur ein Funktionszustand aktiv sein, es können also ausschließlich 
alternative Zweige im Verhalten eines Subjektes dargestellt werden. 
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Generell bietet die BPMN die größte Flexibilität in der Wahl der Darstellungsform 
eines Prozesses. Durch die Vielzahl an Modellierungselementen können auch kom- 
plexe Zusammenhänge kompakt dargestellt werden, was jedoch höhere Ansprüche an 
das Sprachverständnis der Modellnutzenden stellt. Einen anderen Ansatz verfolgen hier 
Aktivitätsdiagramme oder die S-BPM, die auf einem kompakten Satz an Modellierungs- 
elementen aufbauen. Dies führt bei komplexen Zusammenhängen zu umfangreichen 
Modellen, die hohe Ansprüche an die Modellnutzenden hinsichtlich des Modellverständ- 
nisses stellt. Die S-BPM reduziert die unmittelbar sichtbare Komplexität von Modellen 
durch die Verteilung eines Prozesses auf unterschiedliche Subjekte. Während dies zwar 
zu einfach erfassbaren Teilmodellen führt, stellt es gleichzeitig höhere Ansprüche an 
Modellnutzende bei der Erfassung der Gesamtzusammenhänge innerhalb des Prozesses. 

Bei der Auswahl einer für eine gegebene Aufgabenstellung und Zielgruppe geeigneten 
Modellierungssprache ist dem entsprechend nicht nur auf den Abbildungsgegenstand 
(also den betrachteten Geschäftsprozess) Bezug zu nehmen, sondern auch auf die 
bekannten oder vermuteten Kompetenzen der Modellierenden und Modellnutzenden. 
Eine grundlegende Unterscheidung kann zwischen den Sprachen getroffen werden, die 
den Aktivitätsfluss ins Zentrum der Betrachtung rücken (wie die FlowCharts und die 
EPK), und jenen, die die Handelnden eines Prozesses und deren Kommunikation in den 
Vordergrund stellen (wie die S-BPM). 

Die BPMN und Aktivitätsdiagramme eignen sich grundsätzlich für beide Abbildungs- 
arten, wobei die BPMN ausdruckstärkere Mittel zur Abbildung von Kommunikationsab- 
läufen bietet. Die endgültige Auswahl einer Modellierungssprache nach Festlegung des 
grundlegend verfolgten Abbildungsansatzes (Aktivitäts- vs. Kommunikationsfluss) ist 
letztendlich abhängig von den Präferenzen der Modellierenden bzw. Modellnutzenden. 
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Vorgehensweise von der Modellbildung 
zur Digitalisierung 


4.1 Einordnung in den Gesamtzusammenhang 


In den vorangegangenen Kapiteln haben wir gezeigt, dass das Geschehen in Organisa- 
tionen (Unternehmen, Verwaltungen etc.) auf Modellen aus unterschiedlichsten Dis- 
ziplinen basiert. Geschäftsmodelle, Unternehmensarchitekturen mit Modellen für 
Leistungen (Produkte und Services), Aufbauorganisation, Prozesse, Daten und IT-Infra- 
struktur beschreiben, in welchem Bereich ein Unternehmen tätig ist, wie es dies 
bewerkstelligt, in welchen Austauschbeziehungen mit Partnern es steht, von welcher 
technischen Infrastruktur es unterstützt wird usw. 

Bei den Modellierungssprachen haben wir uns auf Ansätze und Notationen für die 
Spezifikation von Geschäftsprozessen und damit die fachliche Gestaltung betrieblicher 
Vorgänge konzentriert. Im Zuge der Digitalisierung sind diese Vorgänge soweit möglich 
und wirtschaftlich sinnvoll mit Informations- und Kommunikationstechnik abzubilden. 
Sowohl den dafür geeigneten inkrementellen Verbesserungen bestehender Prozesse als 
auch grundlegenden Prozessinnovationen liegen kreative Gestaltungsleistungen zugrunde, 
die von den fachlichen Modellen zu ausführbaren Systemen führen sollen. Deshalb 
beschäftigen wir uns im folgenden Kapitel zunächst mit den typischen Aktivitäten des 
Geschäftsprozessmanagements. Mit dem Ansatz des Design Thinking beleuchten wir 
dann einen methodischen Ansatz, um kreativ Neuartiges hervorzubringen und komplexe 
Probleme zu lösen, ehe wir beide Konzepte miteinander in Beziehung setzen. 
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4.2  Aktivitätsbündel im Geschäftsprozessmanagement 
4.2.1 Überblick 


In Abschn. 1.8 haben wir bereits angesprochen, dass die Gestaltung von Geschäfts- 
prozessen bis hin zu ihrer Ausführung als Instanzen bei der Abwicklung konkreter 
Geschäftsvorfälle („operatives Geschäft“) selbst einen Prozess darstellt. Dieser wird häu- 
fig als Geschäftsprozessmanagementzyklus mit Phasen wie Strategie, Entwurf, Imple- 
mentierung und Controlling verstanden [1]. 

In der Praxis sind die Teilaktivitäten aber oft nicht klar voneinander abzugrenzen. 
Wir sehen diese deshalb weniger als Kreis mit sequenzieller Abfolge, sondern eher mit- 
einander vernetzt und verwoben, wie es die Wabenstruktur in Abb. 4.1 andeuten soll. Die 
Darstellung zeigt außerdem, dass wir die Aufgaben etwas stärker differenzieren und als 
Aktivitätsbündel Analyse und Modellierung, Validierung, Optimierung, organisatorische 
Implementierung, IT-Implementierung sowie Betrieb und Monitoring unterscheiden. 

Obwohl die übliche Darstellung als Zyklus suggeriert, dass bei Prozessmanagement- 
vorhaben alle Aktivitätsbündel als Sequenz durchlaufen werden, hängen deren Auswahl 
und Reihenfolge von der konkreten Situation, z. B. vom Reifegrad eines Prozesses ab. 
Abschn. 4.2.2 bis 4.2.7 erläutern die Aktivitäten anhand eines Beispielprozesses. Dabei 
werden die Schritte zunächst komplett und auch in der angegebenen Reihenfolge durch- 
laufen. Ein solches Szenario ist etwa bei der erstmaligen Gestaltung oder einer kom- 
pletten Reorganisation eines Prozesses realistisch. Anschließend diskutieren wir in 
Abschn. 4.2.8 mehrere Szenarien für Verbesserungen, die sich aus den Erfahrungen im 
dem laufenden Betrieb der ursprünglich gestalteten Prozessumgebung ableiten lassen. 
Sie verdeutlichen die situativ unterschiedlichen Pfade durch die Aktivitätsbündel bei der 
Weiterentwicklung des Prozesses. 


Abb. 4.1 Aktivitätsbündel im 
Geschäftsprozessmanagement 
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4.2.2 Analyse und Modellierung 


Die Analyse dient der Erhebung von Informationen, warum ein Prozess existiert bzw. 
implementiert werden soll, welche Ziele eine Organisation mit diesem im Rahmen ihrer 
Strategie verfolgt, und wie in diesem aktuell gearbeitet wird. Ziele sind die Dokumen- 
tation und die Gewinnung von Anhaltspunkten für Verbesserungen. Die Modellierung 
verwendet u.a. die Ergebnisse der Analyse und befasst sich mit der Gestaltung der 
zukünftigen Arbeitsweise, also mit Prozessveränderungen und -innovationen. Wenn dazu 
weitere Informationen nötig sind, wechseln die Beteiligten wieder in den Analysemodus, 
um diese zu erheben, und agieren danach wieder gestaltend. Analyse und Modellierung 
lassen sich deshalb nicht scharf voneinander abgrenzen. Auch Validierung und Optimie- 
rung finden in der Regel bereits hier statt, wenn die Beteiligten das Modell iterativ nach 
besten Wissen und Gewissen und unter Berücksichtigung von in der Analyse erkannten 
Schwachstellen entwickeln und dabei Lösungsmöglichkeiten probieren und diskutieren. 

Neben der Betrachtung von Rahmenbedingungen wie strategischer Bedeutung, Zie- 
len und Risiken geht es bei Analyse und Modellierung im Wesentlichen darum zu ana- 
lysieren bzw. zu spezifizieren (vgl. Abschn. 1.3), 


e welche Handelnden (z. B. Menschen, Maschinen), 

e welche Aktivitäten, 

e nach welchen Geschäftsregeln (Business Rules), 

e an welchen Geschäftsobjekten (z. B. an bestimmte Träger gebundene Informationen, 
physische Gegenstände) 

e mit welchen Hilfsmitteln (z. B. IT-Systeme) ausführen und 

e in welcher Weise sie dabei interagieren, um die gewünschten Prozessziele und -ergeb- 
nisse zu erreichen. 


Zur Entwicklung von Prozessmodellen auf Basis dieser Erkenntnisse bedient man sich 
der in Kap. 3 vorgestellten Modellierungssprachen mit den dazugehörigen grafischen 
Notationen. 

Bei der Analyse und Modellierung wird meist auch bereits eine wesentliche Voraus- 
setzung für das operative Prozesscontrolling in der Betriebsphase geschaffen. Neben den 
bereits genannten Prozessattributen werden dafür Leistungsparameter (Kennzahlen), ins- 
besondere Process Performance Indicators (PPIs), definiert, in einem Messgrößensystem 
systematisiert und mit Zielwerten versehen [2]. Typische Beispiele für PPIs sind Durchlauf- 
zeit, Ausbringungsmenge pro Zeiteinheit, Fehlerrate, Kundenzufriedenheit o. Ä. Die PPIs 
und die dafür geplanten Soll-Werte bilden die Basis für das Geschäftsprozessmonitoring, 
also die operative Prozesskontrolle während der Ausführung (vgl. Abschn. 4.2.7 und 6.3.3). 
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Analyse und Modellierung im Fallbeispiel 

Als Fallbeispiel verwenden wir den stark vereinfacht dargestellten Vorgang der 
Kreditantragsbearbeitung bei einer Bank. Dort gehen Anträge von Interessenten auf 
Gewährung eines Immobiliendarlehens ein. Vor der Erstellung eines Angebots prü- 
fen Sachbearbeiter die Bonität des jeweiligen Kunden und die Werthaltigkeit der zu 
beleihenden Immobilie. Ist das Ergebnis beider Prüfungen positiv, fertigt der Sachbe- 
arbeiter ein Angebot an mit Daten wie Darlehenssumme, Zins- und Tilgungssatz und 
Laufzeit. Beträgt der Darlehensbetrag unter 200.000 € unterschreibt er das Angebot 
und schickt es dem Kunden. Im anderen Fall muss er erst noch die Zustimmung seiner 
Abteilungsleitung und bei mehr als 500.000 € die des Vorstands einholen. Ergeben sich 
aus der Bonitätsprüfung oder der Objektprüfung Anhaltspunkte für Risiken, nimmt ein 
Sachbearbeiter Kontakt mit dem Interessenten auf, um die weitere Vorgehensweise, z. B. 
eine Verminderung der Darlehenssumme, zu abzustimmen. Im Rahmen einer Analyse 
des Prozesses wurden diese Informationen erhoben und strukturiert (vgl. Tab. 4.1). 

Im vorliegenden Fall verwenden wir die in Kap. 3 beschriebene Modellierungs- 
sprache S-BPM zur Darstellung des Prozesses, da dieser in einer stark interaktions- 
orientierten Beschreibung vorliegt. Grundsätzlich wäre die Abbildung mit jeder anderen 
Modellierungssprache, die die Abbildung von Verantwortlichkeiten erlaubt (etwa eEPK 
oder BPMN) ebenso möglich. 


Tab. 4.1 Merkmale des Beispielprozesses und dafür ermittelte Information 


Prozessmerkmal |Erhebungsergebnis 


Akteure/Rollen Interessent, Sachbearbeitung Immobilienkredit, Abteilungsleitung 
Immobilienkredit, Vorstand 


Aktivitäten Kreditantrag stellen, Kreditantrag prüfen (Vollständigkeit), Kundenbonität 
prüfen, Finanzierungsobjekt schätzen, Finanzierungskonditionen ermitteln, 
Angebot erstellen, Angebot genehmigen, Angebot versenden 


Geschäftsobjekte | Kreditantrag mit Anlagen, Kreditangebot 


Geschäftsregeln Kreditangebote über 200.000 € müssen von der Abteilungsleitung 
genehmigt werden, über 500.000 € vom Vorstand. 


Interaktionen Kunde - Bank (Posteingang), Sachbearbeitung Immobilienkredit — 
Abteilungsleitung Immobilienkredit, Abteilungsleitung Immobilienkredit — 
Vorstand, Sachbearbeitung Immobilienkredit — Kunde 


Hilfsmittel Internet-Portal der Bank (Webformular), Bank-System, Workflow-System, 
SCHUFA-Webformular, E-Mail, Telefon 


Prozesskennzahlen | Beobachtung des Verhaltens von Instanzen mithilfe von: 

Durchlaufzeit vom Eintreffen eines Kreditantrags bis zum Versand eines 
Angebots (Ziel: durchschnittlich max. 3 Tage) 

Häufigkeit pro Woche inklusive Verteilung 

Ablehnungsquote von Anträgen seitens Bank 

Ablehnungsquote von Angeboten seitens Interessenten 
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Zusammen mit weiteren Informationen dienten diese Angaben als Basis für die 
Modellierung des Vorgangs. Die folgenden Bilder zeigen einen Auszug des zugehörigen 
Prozessmodells unter Verwendung der Modellierungssprache S-BPM (vgl. Abschn. 3.6). 
Abb. 4.2 stellt die involvierten Subjekte (Handelnde) und die im Prozessablauf aus- 
getauschten Nachrichten dar.Die Kommunikationsstruktur (Subject Interaction Dia- 
gramm, SID) enthält noch keine Reihenfolgen, in denen die jeweiligen Nachtrichten 
ausgetauscht werden. Diese werden im Verhalten der Subjekte beschrieben. Abb. 4.3 und 
4.4 zeigen das Verhalten des Subjekts „Interessent“ und auszugsweise das Verhalten des 
Subjekts „Sachbearbeitung Immobilienkredit“. 

Die nicht abgebildeten Verhaltensspezifikationen der Subjekte „Abteilungsleitung 
Immobilienkredit‘“ und „Vorstand“ sind analog zu beschreiben. Diese Subjekte würden 
in den Prozess involviert werden, wenn die gewünschte Kreditsumme 200.000 bzw. 
500.000 Euro übersteigt. Diese Fälle sind in Abb. 4.4 nicht ausmodelliert — sie wären 
zusätzliche Zweige nach dem Zustand „Freigabe notwendig“. 


4.2.3 Validierung 


Unter Validierung verstehen wir im BPM-Kontext die Überprüfung, ob der gestaltete 
Prozess den vom (externen) Kunden und Prozesseigner erwarteten Output beispielsweise 
in Form eines Service oder Produkts erzeugt. Diese Frage nach der Effektivität bezieht 


fF 4 e fil 4 ; = Das Bild zeigt die Kommunikations- 
B struktur für die Beantragung eines 
Kredits. Die Kommunikation wird 

; [ri] bearbeitung - 
Bi 3 Ummebiienkrui) initiiert vom Handelnden „Interessent“ 
in} (Subjekt). Dieses Subjekt sendet die 


Nachricht Kreditanfrage an das Subjekt 
„Sachbearbeitung Immobilienanfrage“ 
F A und erhält die Nachrichten „Angebot“ 

9 oder „Ablehnung“. 
i Entsprechend den Prozessanfor- 
an derungen tauschen die anderen 
Subjekte die notwendigen Nachrichten 


ti aus. Die Kommunikationsstruktur 
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Abb. 4.2 Kommunikationsstruktur der Handelnden im Prozess Kreditanfrage 
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pP Das Bild zeigt das Verhalten des Subjekts 
formulieren „Interessent“. Im Startzustand (markiert durch 
Kreditanftage erstellt ein Dreieck im Kreis) wird eine Kreditanfrage 
$ formuliert. In der Regel geschieht dies durch das 

Kreditanfrage é Aus-füllen eines entsprechenden Formulars. Die 
senden Inhalte des Formulars wären Bestandteil der Spe- 

To: Sachbearbeitung - Immobilienkredit zifikation des Geschäftsobjekts „Kreditanfrage“. 

Msg: Kreditanfrage i M * 
i T Nachdem die Kreditanfrage erstellt wurde, wird 
diese an das Subjekt „Sachbearbeitung Kredit- 

Auf Antwort PR ` a 
warten anfrage“ gesendet. Danach wird auf eine Ant- 
wort vom Subjekt „Sachbearbeitung Immo- 
From: Sachbearbeitung - Immobilienkredit From: Sachbearbeitung - Immobilienkredit bilienkredit“ gewartet. Dies kann entweder die 
Msg: Angebot Ë na Nachricht „Angebot“ oder „Ablehnung“ sein. In 
| | beiden Fällen ist das Subjektverhalten beendet 
durch erreichen der jeweiligen Endzustände die 
Ele LmielnE P u P als solche durch Punkte gekennzeichnet sind. 
erhalten Kreditanfrage 


Abb. 4.3 Verhalten des Subjekts „Interessent“ 
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Abb. 4.4 Verhalten des Subjekts „Sachbearbeitung Immobilienkredit“ 


sich auch schon auf die Ergebnisse von Teilschritten, also Prozessbeteiligte der eigenen 
Organisation als Kunden. So gilt es beispielsweise zu evaluieren, ob ein vorgelagerter 
Prozessschritt alle Informationen liefert, die ein Bearbeiter bei seiner Teilaufgabe für 
eine Entscheidung (z. B. Genehmigung) benötigt. Wir haben bereits angesprochen, dass 
ein Modell schon während seiner schrittweisen Entwicklung immer wieder in Teilen 
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der Validierung unterzogen wird. Objekt der Validierung ist darüber hinaus das kom- 
plett fertiggestellte Prozessmodell, dessen Effektivität sichergestellt sein sollte, ehe es 
informationstechnisch umgesetzt wird (vgl. Abschn. 4.2.6). Sonst werden Fehler erst 
spät entdeckt und verursachen entsprechend hohe Kosten für ihre Beseitigung. 


Validierung im Fallbeispiel 

Das Prozessmodell für den Beispielvorgang wurde während seiner Entwicklung 
sowie abschließend validiert. Dabei wurde zum Beispiel zunächst festgestellt, dass im 
ursprünglichen Kreditantrag kein Feld für das Beschäftigungsverhältnis des Antrag- 
stellers vorgesehen war und somit eine wichtige Angabe zur Risikobeurteilung fehlt. 
Dies führte zur Erweiterung des Geschäftsobjektes und zu einem positiven Validierungs- 
ergebnis bei der entsprechenden Iteration. 


4.2.4 Optimierung 


Während die Validierung die Sicherstellung der Effektivität von Geschäftsprozessen 
zum Ziel hat, geht es bei der Optimierung um die Effizienz. Prozesseffizienz lässt sich 
über Prozessattribute zur Ressourcenbeanspruchung wie Dauer und Kosten fassen. Opti- 
mierung bedeutet, eine im Hinblick auf solche Prozessparameter optimale Gestaltung 
eines Prozesses zu finden. Wesentliche Ansatzpunkte sind Verbesserungen der ablauf- 
organisatorischen und aufbauorganisatorischen Gestaltung sowie der IT-Unterstützung. 
Die Optimierung ist demnach streng genommen kein eigenständiges Aktivitätsbündel, 
sondern bedient sich der Modellierung, der organisatorischen Implementierung und der 
IT-Implementierung (vgl. Abschn. 4.2.2, 4.2.5 und 4.2.6). 

Eine bekannte Methode für den Vergleich von Alternativen im Ablauf oder beim 
Ressourceneinsatz ist die Simulation. Mit ihrer Hilfe lassen sich für eine größere 
Menge von Prozessinstanzen (Aufträge, Fertigungsstücke etc.) quantitative Aussagen 
über die Entwicklung von Prozessparametern gewinnen. Die Simulation ermöglicht die 
Bewertung eines Prozessmodells mit einer bestimmten Kombination von Parametern. 
Dies können deterministische oder auch stochastische, durch Wahrscheinlichkeits- 
verteilungen beschriebene Größen sein. Durch Parameteränderungen und alternative 
Prozessgestaltungen können verschiedene Gestaltungsoptionen in ihrem Verhalten ana- 
lysiert werden. Damit lassen sich Erkenntnisse über Engpässe bzw. Ineffizienzen und die 
Sensitivität von Parametern gewinnen. Der Aufwand für die Erweiterung eines Prozess- 
modells und für die Beschaffung notwendiger Informationen, um Simulationen durch- 
führen zu können, kann beträchtlich sein.Eine Schwierigkeit bei der Optimierung besteht 
darin, dass die relevanten Attribute oft interdependent und in ihrer Veränderung einander 
gegenläufig sind. So kann es sein, dass eine Prozessalternative relativ zu einer anderen 
zwar eine geringere Durchlaufzeit, dafür aber höhere Kosten aufweist. Die Entscheidung 
für eine Alternative hängt damit auch von der Priorität der Prozessziele ab. 
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Optimierung im Fallbeispiel 

Das Modell konnte bereits bei seiner Entstehung optimiert werden, und zwar durch die 
Parallelisierung der zunächst sequenziell geplanten Schritte zur Prüfung der Kunden- 
bonität und der Werthaltigkeit der Immobilie. 


4.2.5 Organisatorische Implementierung 


Validierte Prozesse müssen für den Produktivbetrieb in die bestehende und gegebenen- 
falls neu zu gestaltende organisatorische Umgebung eingebettet werden. Dies erfordert 
i. d. R. eine Anpassung der sie umgebenden Ablauf- und Aufbauorganisation.Ein einzel- 
ner Prozess ist meist Teil einer gesamten Wertschöpfungsumgebung (Wertschöpfungs- 
kette, Wertschöpfungsnetz), in die er sich nahtlos einfügen muss. Im Hinblick auf die 
ablauforganisatorische Integration in die Prozesslandkarte sind deshalb insbesondere 
die Schnittstellen mit anderen Prozessen zu betrachten. Dies kann dazu führen, dass an 
Schnittstellen eines vor- oder nachgelagerten Prozesses Änderungen durchzuführen sind. 
Solche Sachverhalte sind im Regelfall bereits in den vorgelagerten Aktivitätsbündeln 
berücksichtigt. Bei der Implementierung darf es deshalb letztlich nur noch um die zeit- 
liche Synchronisation der Produktivsetzung gehen. Damit ist gemeint, dass Prozesse, die 
über Schnittstellen verbunden sind, gleichzeitig erneut produktiv gesetzt werden müssen, 
wenn sich an einer Schnittstelle eine Veränderung ergeben hat, die auch beim Partner- 
prozess Modifikationen nötig gemacht hat. 

Die aufbauorganisatorische Einbettung umfasst die Zuordnung von konkreten Hand- 
lungsträgern, also letztlich Menschen als Stellen- oder Rolleninhaber, zu den im Modell 
abstrakt spezifizierten Akteuren. Herausforderung ist dabei u.a. die Berücksichtigung 
des organisatorischen Kontexts beim Einsatz von Workflow Engines. Diese müssen etwa 
zur Laufzeit dynamische Vertreterregelungen ebenso auflösen können wie die Tatsache, 
dass Personen im selben Prozess verschiedene Rollen bekleiden können. Beispielsweise 
kann eine vorgesetzte Person im Urlaubsantragsprozess der Genehmiger von Urlaubs- 
anträgen der eigenen Mitarbeiterinnen und Mitarbeiter sein, selbst aber auch Antrag- 
steller für den eigenen Urlaub sein, den wiederum der eigene Vorgesetzte genehmigen 
muss. Für die korrekte Steuerung einer Instanz durch die Bearbeitungsstellen und — 
schritte muss die Software also Organisationswissen besitzen.Bei der organisatorischen 
Einbettung sind weitere qualitative und quantitative Aspekte zu berücksichtigen. So 
ist darauf zu achten, dass die Mitarbeiterinnen und Mitarbeiter die für die Ausführung 
des modellierten Verhaltens nötigen Qualifikationen (Skills) besitzen oder durch Schu- 
lungen erwerben können. Adäquate Qualifikation ist nicht nur Voraussetzung für eine 
erfolgreiche Arbeit im aktuell gültigen Prozess, sondern fördert auch Impulse für Ver- 
besserungen seitens der Prozessbeteiligten. 

Die Anzahl der Personen, die den abstrakten Akteuren im Modell zugeordnet werden, 
beeinflusst die Kapazität für die Bearbeitung von Prozessinstanzen und wirkt sich damit 
auf Parameter wie die Durchlaufzeit aus. 
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Tab. 4.2 Potenzielle und konkrete Besetzung von Rollen 


Akteur/Rolle ] Anzahl gesamt | Zugeordnet gemäß Personaleinsatzplan 
Sachbearbeitung Immobilienkredit | 9 | 5 Kräfte in Vollzeit 
Abteilungsleitung Immobilienkredit 1 |1 Leiter 


| 1 Stellvertreter (Leiter Konsumentenkredit) 
13 | 1 Ressortleiter Privatkunden 
| 1 Ressortleiter Geschäftskunden 


| 1 Ressortleiter Anlagemanagement 


Vorstand 


Organisatorische Implementierung im Fallbeispiel 

Den identifizierten und modellierten Rollen wurde die in Spalte 2 in Tab. 4.2 aufgeführte 
Zahl von Mitarbeiterinnen und Mitarbeitern zugeordnet, welche die Rolle aufgrund 
ihrer Qualifikation prinzipiell besetzen können. Die dritte Spalte enthält die tatsächliche 
eingesetzte Kapazität (kurzfristige Ausfälle z. B. wegen Krankheit sind nicht berück- 
sichtigt). Die Abteilungsleitungen für Immobilien- und Konsumentenkredite vertreten 
sich gegenseitig sowohl in disziplinarischen als auch in fachlichen Angelegenheiten. 
Dies gilt analog für die Vorstände. 


4.2.6 IT-Implementierung 


Die meisten Prozesse sind ohne IT-Unterstützung nicht wirtschaftlich auszuführen. Ins- 
besondere wenn ein hoher Automatisierungsgrad eines Ablaufes angestrebt wird, erlangt 
die Qualität der Abbildung in der IT hohe Bedeutung. Aber auch oder gerade an Stellen, 
wo der menschliche Bearbeiter involviert ist (z. B. Eingaben tätigen, Entscheidungen tref- 
fen), muss viel Wert auf die bedarfsgerechte Gestaltung der IT-Systeme gelegt werden. 

Die IT-bezogene Implementierung eines Prozesses bedeutet, ihn als IT-gestützten 
Workflow unter Integration einer geeigneten Benutzeroberfläche, der Ablauflogik und 
der beteiligten IT-Systeme abzubilden. Dazu gilt es zunächst, die mehr oder weniger for- 
male Modellbeschreibung (vgl. Kap. 3) in eine von einer Workflow Engine interpretier- 
bare Sprache, d.h. ein ablauffähiges Programm zu überführen. Damit kann die Engine 
die Abarbeitung einer Prozessinstanz zur Laufzeit gemäß dem Modell steuern. Für die 
Erledigung einzelner Teilaufgaben bei der Abarbeitung sind meist eine ganze Reihe 
von Softwareapplikationen und — Services in den Ablauf zu integrieren. Typische Bei- 
spiele sind ERP-Transaktionen und Dokumenten- und Content-Management-Systeme. 
Ausgiebige Tests der implementierten Lösungen müssen die Qualität der Prozessunter- 
stützung durch IT sichern. 


IT-Implementierung im Fallbeispiel 

Tab. 4.3 zeigt die wesentlichen Elemente der IT-Umgebung, welche zur Unterstützung 
des Prozesses und seiner Teilschritte aufgebaut wurde, zusammen mit ihren wichtigsten 
prozessrelevanten Funktionen. 
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Tab. 4.3 Realisierte IT-Umgebung des Prozesses 


IT-System/-Service | Auswahl für den Prozess wesentlicher Funktionen 


Portal der Bank | Stellt Informationsmaterial zur Finanzierung und elektronisches Formular 
| zur Erfassung des Kreditantrags durch den Kunden oder einen Sachbe- 
arbeiter Immobilienkredit zur Verfügung 


Workflow Engine |Instanziiert Vorgang beim Speichern des Antrags durch den Kunden im Portal. 
| Steuert die Instanzen gemäß Modell und bindet dabei bei Bedarf Benutzer 
und andere Systeme oder Services ein. 

Zeichnet Log-Daten zu den Vorgängen auf. 

| Erzeugt Meldungen und Berichte auf Basis der Log-Daten 


Verwaltet Kunden 
Kategorisiert Kunden (Scoring) 
| Ermittelt Konditionen 

Erzeugt Angebote 


Banksystem 


4.2.7 Betrieb und Monitoring 


Implementierte Prozesse gehen nach der Abnahme in den Echtbetrieb (Going Live). 
Dies bedeutet, dass die Prozessbeteiligten sie in der aufgebauten organisatorischen und 
informationstechnischen Umgebung im Tagesgeschäft in Form von Instanzen ausführen. 

Für die Gewinnung von Information für das bewusste Management der Prozesse ist 
die Beobachtung ihres Verhaltens im laufenden Betrieb nötig. Dieses Monitoring nimmt 
Messdaten auf und berechnet daraus Ist-Werte für die bei der Analyse und Modellie- 
rung definierten Process Performance Indicators. Ein sofortiger Vergleich mit definierten 
Soll-Größen führt bei Abweichungen zu Eskalationen entlang der Managementhierarchie 
und gegebenenfalls zu kurzfristigen Maßnahmen. Mittel- und längerfristige Aus- 
wertungen lassen strukturelle Verbesserungsmöglichkeiten erkennen. Die Analyse des 
Prozessverhaltens und möglicher Abweichungen lässt Rückschlüsse auf Ursachen zu und 
löst Rückkopplungen in andere Aktivitätsbündel aus. 


Betrieb und Monitoring im Fallbeispiel 

Seit Freigabe des Prozesses arbeitet die Bank Kreditanträge der Interessenten in der 
beschriebenen Form und Umgebung ab. Das Monitoring für das vergangene Quartal 
ergab folgende durchschnittliche Zahlen: 


e Interessenten haben 50 Anträge pro Woche gestellt 

e Die Bank hat 20% davon abgelehnt, die Hälfte davon wegen mangelnder Bonität 

e Zu den restlichen Anträgen erhielt der Interessent ein Angebot innerhalb von 4 Tagen 

e In 30% der Fälle hat der Interessent das Angebot angenommen und einen Vertrag 
abgeschlossen 
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Da Mitbewerber mit sehr kurzen Bearbeitungszeiten werben, nimmt die Bank an, dass 
die Dauer von 4 Tagen bis zum Erhalt eines Angebots bei sonst vergleichbaren Kondi- 
tionen einer der Gründe ist, warum Kunden keinen Vertrag abschließen. Sie weicht auch 
signifikant vom vorab formulierten Ziel von 3 Tagen ab. 


4.2.8 Verbesserungsszenarien 


Die folgenden Szenarien zeigen, wie mit weiterführenden Analysen der Monitoring-Er- 
gebnisse nach Ursachen für die lange Durchlaufzeit geforscht, und für Verbesserungs- 
maßnahmen (Optimierung) in passende Aktivitätsbündel verzweigt werden kann. Davon 
hängt im Einzelfall der weitere Pfad durch die Aktivitätsbündel ab, also welche Tätig- 
keiten anschließend nötig sind, ehe der umgestaltete Prozess produktiv gesetzt werden 
kann. Die Ausführungen beschränken sich zur Vereinfachung jeweils auf eine Maßnahme. 
In der Realität wird man meist mehrere Optimierungsmöglichkeiten parallel verfolgen. 


4.2.8.1 Verbesserungsszenario 1 

Die Betrachtung der Häufigkeitsverteilung für den Anfall der Kreditanträge hat ergeben, 
dass montags 25, dienstags 15, mittwochs 6 und donnerstags und freitags je 2 Anträge 
vorliegen. Dies könnte daran liegen, dass Interessenten am Wochenende vermehrt 
Immobilien besichtigen, Kaufentscheidungen treffen und die Finanzierung angehen. Die 
Auswertung der Liegezeit bis zur Bearbeitung durch die Sachbearbeitung Immobilien- 
kredit zeigt, dass dort zu Wochenbeginn wegen des hohen Aufkommens ein Engpass vor- 
liegt. Bei der derzeit vorgehaltenen Kapazität von 5 Sachbearbeitern in Vollzeit beträgt 
die durchschnittliche Liegezeit 2 Tage. Um diese und damit die Durchlaufzeit zu ver- 
ringern, könnte im Rahmen der organisatorischen Implementierung an den Montagen 
und Dienstagen zusätzliche Sachbearbeitungskapazität, etwa in Form verfügbarer Halb- 
tageskräfte eingesetzt werden. In diesem Fall ändert sich der Prozess nicht, es sind keine 
weiteren Aktivitäten nötig. 


4.2.8.2 Verbesserungsszenario 2 

Eine genauere Analyse hat ergeben, dass die hohe durchschnittliche Durchlaufzeit von 
den Anträgen mit Beträgen zwischen 200.000 € und 500.000 Mio. € verursacht wird, 
weil die Liegezeit bis zur Genehmigung durch die Abteilungsleitung relativ zu den ande- 
ren Anteilen der Gesamtdauer sehr hoch ist. Dies liegt daran, dass Abteilungsleitung und 
Stellvertretung z. B. wegen häufigen Dienstreisen nicht regelmäßig für Genehmigungen 
zur Verfügung stehen.Der interne Prozessberater der Bank schlägt eine Änderung der 
Geschäftsregel zur Genehmigung vor. Zukünftig soll es den Sachbearbeitern erlaubt 
sein, für Beträge bis 500.000 € Angebote selbst zu unterschreiben und zu verschicken. 
Diese Reorganisation berührt mehrere Aktivitätsbündel. Zunächst erfordert sie eine 
Änderung des Modells, da die Genehmigungsschleife über die Abteilungsleitung entfällt. 
Die Modelländerung bedarf der anschließenden Validierung, um sicherzustellen, dass 
der geänderte Ablauf (immer noch) zum gewünschten Ergebnis führt. Im Rahmen der 
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IT-Implementierung muss die Modifikation des Modells auch in die Workflow-Software 
überführt und getestet werden.Durch den Wegfall der Genehmigungen ändert sich der 
Aufgabenzuschnitt bei der Abteilungsleitung. Bei der Sachbearbeitung bleiben die Auf- 
gaben zwar gleich, jedoch erhöhen sich Kompetenz und Verantwortung. Diesen Ände- 
rungen ist in der organisatorischen Implementierung Rechnung zu tragen, etwa durch 
aktualisierte Aufgabenbeschreibungen und möglicherweise durch Qualifikation der 
Sachbearbeiter mithilfe von Schulungen z. B. zur umfangreicheren Risikoabschätzung. 
Dieses Szenario greift im Vergleich zum Fall 1 massiv in die Art ein, wie im Prozess 
gearbeitet wird, und erfordert deshalb wesentlich umfangreichere Aktivitäten. 


4.2.8.3 Verbesserungsszenario 3 

Die Bank holt Bonitätsdaten über die Antragsteller bei der Schutzgemeinschaft für 
allgemeine Kreditsicherung (SCHUFA) ein. Hierzu übertragen die Sachbearbeiter 
Immobilienkredit die nötigen Kundendaten aus dem Kreditantrag in das Web-Formular 
der SCHUFA und die von dort gelieferten Abfrageergebnisse in das Bank-System zur 
weiteren Verarbeitung im bankeigenen Scoring. Die Sachbearbeiter berichten vom zeit- 
raubenden Umkopieren der Daten durch Copy & Paste, den Fehlern die dabei entstehen, 
und den dadurch verursachten Nacharbeiten. 

Um die Digitalisierung weiter voranzutreiben entscheidet die Bank ohne weitere Ana- 
lysen, zukünftig anstatt der Internetauskunft der SCHUFA deren Web-Service zu nut- 
zen. Dieser kann in den Workflow so integriert werden, dass die Process Engine ihn auf 
Knopfdruck des Sachbearbeiters aufruft und ihm die Kundendaten als Parameter über- 
gibt. Der Service liefert das Ergebnis automatisch zurück an die Process Engine, die es 
in das Banksystem überträgt.Zu behandelnde Aktivitätsbündel beschränken sich in die- 
sem Fall auf die IT-Implementierung, in deren Rahmen die entsprechenden Software- 
anpassungen mit anschließenden Tests durchzuführen sind, ehe die Produktivsetzung 
erfolgt. Die Arbeitsweise der Beteiligten ändert sich nur geringfügig, es sind keine Qua- 
lifizierungsmaßnahmen nötig. Der Wegfall der manuellen Datenübertragung entlastet sie 
von stupiden, zeit- und damit kostenintensiven und fehleranfälligen Routinetätigkeiten. 
Der intensivere IT-Einsatz spart Bearbeitungs- und Durchlaufzeit sowie Kosten und 
erhöht die Kundenzufriedenheit. 


4.2.8.4 Verbesserungsszenario 4 
In Abschn. 4.2.4 haben wir beschrieben, dass bei der Modellierung die Kundenboni- 
tätsprüfung und die Objektprüfung bewusst parallelisiert wurden, um Durchlaufzeit zu 
sparen. Die Analyse hat gezeigt, dass die Bank pro Woche fünf Anträge aus Bonitäts- 
gründen ablehnt. In diesen Fällen haben aber Sachbearbeiter bereits Aufwand für die 
parallele Wertprüfung der betreffenden Immobilien betrieben. Diesen einzusparen könnte 
zunächst wieder dafür sprechen zuerst die Bonität zu prüfen und nur bei positivem 
Ergebnis die Wertprüfung durchzuführen. Nötig wäre eine Modelländerung mit Validie- 
rung und Anpassung der Workflow-Anwendung. 

Die Rückführung der arbeitsteiligen Prüfung würde aber wieder die Durchlaufzeit 
erhöhen und zu einem Zielkonflikt führen. Deshalb gilt es weiter zu überlegen, ob sich 
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der Aufwand für die Wertprüfung durch Automatisierung vermindern lässt, sodass eine 
unnötige Prüfung nicht mehr ins Gewicht fällt. Denkbar ist z. B., dass das Banksystem 
um Funktionen zur Bewertung erweitert wird. Es könnte dann nach automatischer Über- 
nahme von Parametern aus dem Kreditantrag (Art, Größe, Baujahr, Adresse etc.) und 
angereichert mit Vergleichsinformationen (bankeigene Erfahrungswerte und Richtwert- 
tabellen) und Geoinformationen (Infrastruktur mit Schulen, Einkaufsmöglichkeiten, 
Verkehrsanbindung etc.) einen Wertindex errechnen. Dieser beschleunigt die vom Sach- 
bearbeiter vorgenommene finale Werteinschätzung. Bei dieser Möglichkeit könnte die 
parallele Ausführung der Schritte bestehen bleiben. 

Anstelle einer Modelländerung wären die Zusatzfunktionalität in der IT-Implementie- 
rung zu realisieren und zu testen sowie die Sachbearbeiter im Umgang mit der Software- 
erweiterung zu schulen. 


4.3 Einführung in Design Thinking 
4.3.1 Wesen 


Design Thinking (DT) ist ein methodischer Ansatz, kreativ und gestalterisch tätig zu 
werden, um Neuartiges hervorzubringen und komplexe Probleme zu lösen. Es zeichnet 
sich durch Beschreiten neuartiger Wege zur lösungsorientierten Gestaltung aus. Problem- 
stellungen können besser gelöst werden, indem bei fortlaufenden Iterationen und dem 
„Begreifbarmachen“ durch Prototypen die Bedürfnisse der (potenziellen) Nutzer in den 
Vordergrund gestellt werden. Über dieses grundlegende Verständnis von Design Thin- 
king herrscht Einigkeit in Praxis und Wissenschaft!. Das Spektrum, das der Ansatz 
abdeckt, wird dagegen nicht einheitlich gesehen. 

Es gibt beispielsweise Interpretationen als Denkweise, Prozess und Werkzeugkasten 
[4]. Eine empirische Untersuchung belegt die Wahrnehmung im Kontinuum zwischen 
den beiden Polen Werkzeugkasten und Mindset (vgl. Abb. 4.5) [5]. 

Dies ist einerseits auf die unterschiedlichen Wurzeln zurückzuführen, andererseits 
aber auch eine Folge der dem Konzept inhärenten, stetigen, erfahrungsgeleiteten Weiter- 
entwicklung und Anpassung in unterschiedlichen Kontexten. „Die ständige Weiter- 
entwicklung ist ein wichtiger Teil von Design Thinking“ [6]. konstatiert Larry Leifer, 
einer der Protagonisten des Ansatzes an der d.school in Stanford, und betont: „Wenn 
Design Thinking eines Tages ein festgeschriebenes Manifest herausgeben sollte, würde 
es sich damit selber unkenntlich machen“ [6, S. 9]. 

Der Ansatz geht auf David Kelley von der Design-Agentur IDEO und die Professo- 
ren Larry Leifer und Terry Winograd von der Universität Stanford zurück. Insbesondere 
letztere stellten bei der Ingenieursausbildung fest, dass bei der Entwicklung markt- 
fähiger Produkt weniger die rein technischen, sondern vielmehr nutzerbezogene Aspekte 


"Eine Übersicht über Definitionen findet sich z.B. bei [3]. 
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Tool(box) 

Tools with clear rules and 
instruction manuals, e.g.: 
Empathy Map, POV, 
MadLib, Brainstorming 
Rules, Stakeholder Map, 
etc. Many tools come with 
steps how to apply them. 
The more complex these 
steps become, the more 
they are perceived as self- 
contained methods. 
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Method/Process/Protocol 
A means or manner of 
procedure to systematically 
get things done and know 
when to apply which tool 
(with ist sub-steps) to the 
situation at hand. Often 
understood as a (semi-) 
ordered sequence of 
actions, for example the x 
steps in ‘the’ design 
thinking process, waterfall 
model, or other process 
representations. 


Methodology 


Methodology 

Combining and mastering a 
set of appropriate methods 
and methodologies, i.e. the 
principles, practices, and 
procedures of different 
knowledge domains (e.g., 
ethnographic research + 
industrial design + 
creativity methods etc.), 
which might constitute a 
coherent whole for an 
application context at 
hand. Examples might be 


Mindset 


spiritual, 
philosophical 


Mindset 

A guiding stance or 
attitude, which influences 
ways of reasoning. As such 
it shapes the selection and 
development of 
appropriate 
methodologies, methods 
and tools. The frequent 
application of the latter 
three might influence the 
mindset and vice versa. 


Lean Start-up, Six Sigma or 
Design Thinking itself. 


Abb. 4.5 Verständnis von Design Thinking 


im Mittelpunkt stehen sollten. Diese Erkenntnis führte etwa ab den 1980er-Jahren zur 
Entwicklung des DT-Konzepts und manifestiert sich bis heute im Stanford-Kurs zum 
Mechanical Engineering 310 — Design Innovation (me310.stanford.edu). Zur weiteren 
Verbreitung in Forschung, akademischer Lehre und betrieblicher Praxis trug maßge- 
blich Hasso Plattner mit seiner Unterstützung der nach ihm benannten Einrichtungen des 
d.school Institute of Design an der Universität Stanford und der School of Design Thin- 
king an der Universität Potsdam (HPI D-School) bei. 

Aufgrund der Herkunft war DT ursprünglich vorwiegend auf die Entwicklung von 
physischen Produkten bezogen. Es findet aber mittlerweile vielfältige Anwendung 
in unterschiedlichen Gebieten wie bei der Entwicklung von Services oder ganzer 
Geschäftsmodelle, und gewinnt auch vermehrt in der Organisationsgestaltung und im 
Geschäftsprozessmanagement an Bedeutung. 


4.3.2 Kernelemente 


Kernelemente sind eine Mischung aus Mindset, Vorgehensweisen und konkreten Ein- 
richtungen wie Arbeitsräumen. Dies spiegelt sich in der groben Einteilung in die drei 
„Ps“ wider, nämlich in die Bereiche People (Menschen), Process (Prozess) und Place 
(Arbeitsumgebung). 

Design Thinking beginnt mit der Schaffung tiefer Empathie für die Betroffenen. Es 
identifiziert die optimale Lösung im Überlappungsbereich von Wünschen der Menschen 
(menschlich-psychologischer Aspekt), der Machbarkeit (technologischer Aspekt) und 
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Wirtschaftlichkeit (geschäftlicher Aspekt) [7]. Die zu entwickelnde Innovation soll etwas 
sein, das 


e die Menschen wirklich mögen (desirability), 
e aus technologischer und prozessualer Sicht machbar ist (feasibility) und 
e aus wirtschaftlicher Sicht erfolgreich ist (viability). 


Um dies zu erreichen durchläuft ein interdisziplinäres Team (People) in variablen, 
Kreativität fördernden Räumlichkeiten (Place) einen Prozess (Process) mit vielen Itera- 
tionen, wobei eine Vielzahl von Methoden zum Einsatz kommen kann. 


4.3.2.1 People 
Die Fokussierung auf den Menschen erfolgt in zweierlei Hinsicht: 

Zum einen stehen Vertreter der Zielgruppe der Innovation, d. h. Kunden oder 
Anwender, mit ihren Bedürfnissen im Vordergrund. Empathie für sie zu entwickeln, sich 
in ihre Lage im betrachteten Kontext zu versetzen und somit ein tiefes Problemverständ- 
nis zu erlangen, ist der Grundstein für erfolgreiche Innovation und nimmt breiten Raum 
in dem im Abschn. 4.3.2.2 beschriebenen Prozess ein. 

Zum zweiten stellt Design Thinking stark auf die am Projekt beteiligten Menschen als 
Einzelpersonen und als Team ab. Es sieht vor, die Diversität in interdisziplinären Teams 
für die Erhöhung der Ergebnisqualität zu nutzen. Teammitglieder sollen „T-Shaped“, 
d. h. sowohl Experten als auch Generalisten sein. Als Experten sind sie tief verwurzelt 
in ihrem Fachgebiet und bringen die entsprechende Expertise ein (senkrechter Strich des 
T). Damit kann auch die fachliche Vertretung einer Interessengruppe (Stakeholder) ein- 
hergehen (z. B. Vertrieb, Produktion, IT). Der Blick aus unterschiedlichen Perspektiven 
auf eine Problemstellung und die Synthese von Know-how und Erfahrungen aus ver- 
schiedenen Domänen hilft oft, neuartige Lösungsansätze zu entwickeln. 

Die Eigenschaft als Generalisten ist Voraussetzung dafür, von der eigenen Perspektive 
in die von anderen Beteiligten zu wechseln und offen zu sein für die Zusammenarbeit an 
den (fachlichen) Schnittstellen (waagrechter Strich des T, „Wir“-Denken) [8, S. 122 ff.]. 
Lewrick et al. plädieren deshalb für interdisziplinäre versus multidisziplinäre Teams, weil 
erstere wirklich kollektiv Ideen hervorbringen und hinter diesen stehen, wogegen die 
Mitglieder multidisziplinärer Teams bei der Lösungsfindung oft die eigene Perspektive 
überbewerten. Letzteres führt eher zu Kompromisslösungen, die nicht von allen hundert- 
prozentig mitgetragen werden [8]. Ein interdisziplinäres Team ist idealerweise heterogen 
zusammengesetzt, nicht nur aus Vertretern möglichst vieler Fachgebiete, sondern auch 
unterschiedlicher Altersgruppen, Nationalitäten und Geschlechter. 

Der Erfolg eines Design-Thinking-Projektes wird maßgeblich durch die individuel- 
len Eigenschaften der Mitglieder dieses Teams und der daraus erwachsenden gemein- 
schaftlichen Arbeitskultur und Denkweise bestimmt. Im Zentrum steht dabei, dem 
Menschen als Ausgangspunkt aller Aktivitäten hohe Wertschätzung und Empathie ent- 
gegenzubringen, sowohl den Kolleginnen und Kollegen im Team als auch den Benutzern 
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bzw. Kunden. Dazu sollen Eigenschaften kommen wie Kooperationsfähigkeit, Neugier, 
Experimentierfreude, integratives Denken und Optimismus der Teammitglieder. Ein 
weiterer Erfolgsfaktor ist die Begleitung des Teams durch eine mit dem Prozess und 
dem Methodeneinsatz erfahrene Person als Facilitator. Diese gibt Orientierung über das 
jeweilige Stadium im Prozess und welche Instrumente dort am besten zu verwenden 
sind, ohne jedoch inhaltlich zu intervenieren. 


4.3.2.2 Process 

Design Thinking folgt einem Vorgehensmodell mit einer Reihe von Schritten. Zwar 
haben sich mit der Zeit leicht unterschiedliche Varianten des sogenannten Mikrozyklus 
mit alternativen Bezeichnungen der Phasen herausgebildet, welche aber inhaltlich letzt- 
lich kaum voneinander abweichen. Wir orientieren uns an dem Modell der d.school in 
Stanford, das dem Design-Thinking-Prozess fünf auch als Arbeitsmodi bezeichnete Pha- 
sen zugrunde legt (vgl. Abb. 4.6). 

Gekennzeichnet sind alle Modelle vom Wechsel zwischen divergentem und kon- 
vergentem Betrachten, Denken und Agieren, sowohl beim Verstehen des Problemraums 
und Gestalten des Lösungsraums. Der Übergang zwischen der Ausweitung des kreati- 
ven Rahmens mit stetig zunehmender Informationsmenge und dem Fokussieren durch 
Eingrenzung wird als Groan Zone bezeichnet, also als eine Stelle wie ein „knarzendes“ 
Scharnier [8, S. 28 f.]. Auch die bewusste Iteration ist ein grundlegendes Element im 
DT-Prozess, das sich in dem Motto „fail early, fail often“ bzw. „fail forward“ in einer 
offenen Fehlerkultur äußert. Es beschreibt die Vorstellung, dass ideale Lösungen nur 
durch mehrfaches frühzeitiges Experimentieren, Testen und Berücksichtigen des Feed- 
backs der Zielgruppe gefunden werden können, was zu mehr oder weniger umfang- 
reichen neuen Durchläufen früherer Modi führen kann. Die mehrfachen Iterationen 
sollen als sogenannter Makrozyklus vom Problemverständnis zur Konkretisierung einer 
Lösungsvision führen und in einem Umsetzungsplan münden [8, S. 37 £.]. 

In allen Prozessphasen gilt das Prinzip „Be visual & show“, was bedeutet, dass 
Gedanken, Ideen, Ergebnisse visuell und plastisch dokumentiert und vorgeführt werden 
sollen, etwa durch Post-its mit Stichworten und Zeichnungen, Mindmaps, Process Maps, 
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greifbare Prototypen etc. Aufgrund dieses Prinzips wird manchmal auch vorgeschlagen, 
besser von Design Doing anstatt von Design Thinking zu sprechen. 

Für die erfolgreiche Arbeit eines Teams entlang des Prozesses hat sich eine Reihe 
von Regeln und Tipps (Rules of Engagement) als hilfreich erwiesen, von denen einige 
auch generell bei Gruppenarbeiten zu beachten sind. Sie sollten zu Beginn eines Projekts 
kommuniziert und im weiteren Verlauf vom Facilitator bei Bedarf in Erinnerung gerufen 
werden: 


e Nutzerorientierte Denk- und Arbeitsweise (Entwicklung vom Empathie) 

e Keine Vorgabe oder Beschränkung von Denkweisen, Lösungswegen oder Lösungen 
(Offenheit, Autonomie; „Go for quantity‘“) 

e Konzentration auf das Thema (Fokussiertheit), daher auch keine Ablenkung durch 
Handys, Computer, iPads, Smart Watches etc., es sei denn sie sollen bewusst z. B. für 
Recherchen oder zur Prototyperstellung eingesetzt werden 

e Aktive Teilnahme jedes Teammitglieds (eigene Artikulation, diszipliniertes Zuhören 
(„One conversation at a time“) und Aufbauen auf Ideen anderer) 

e Förderung der Entwicklung unterschiedlicher Perspektiven und wilder Ideen (,Encou- 
rage wild ideas“) 

e Keine Wertungen bei der Ideengenerierung (,„Defer judgement“, „No killer phrases“) 

e Zeitlimitierung („Time Boxing“), um Verliebtheit in eine bestimmte Idee zu ver- 
meiden 


Die folgenden Abschnitte beschreiben jede Phase kurz zusammen mit einer tabellari- 
schen Auswahl an Methoden und Werkzeugen, welche dort zum Einsatz kommen. Aus- 
führlichere Erläuterungen dazu finden sich beispielsweise im Bootcamp Bootleg der 
d.school [9] und bei [8, S. 36 ff.]. 


Empathize (Empathie aufbauen) 

Empathie ist das Herzstück eines menschen-zentrierten Designprozesses. Sie zu ent- 
wickeln heißt, ein tiefes Verständnis für die Mitglieder der Zielgruppe aufzubauen im 
Hinblick auf die Problemstellung und deren Kontext. Ziel ist es zu verstehen, warum 
und wie die Menschen Dinge tun, wie sie über die Welt denken und was ihnen wichtig 
ist und sinnvoll erscheint, sowie etwas über ihre körperlichen und emotionalen Bedürf- 
nisse zu erfahren. Dies bedeutet die Nutzer zu beobachten, ihnen zuzuhören, mit ihnen 
zu interagieren, sich in ihre Situation einzudenken und einzufühlen und damit in ihre 
bewusste und unbewusste Welt von Gefühlen, Werten und Bedürfnissen einzutauchen 
(engage, observe, immerse). Dies ist die Grundvoraussetzung, um Innovationen in die 
richtige Richtung zu lenken. 

Ein wesentliches Instrument zur Dokumentation des Verständnisses für die Ziel- 
gruppe sind die sogenannten Personas. Sie stellen fiktive Kunden oder Benutzer dar 
und verkörpern deren unterschiedliche Ziele, Verhaltensweisen, Bedürfnisse und Eigen- 
schaften mit Relevanz für die zu entwickelnde Lösung. 
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Tab. 4.4 Methoden und Werkzeuge für die Phase „Empathize“ 


Aktivität/Thema Ausgewählte Methoden bzw. Werkzeuge 
Problemkontext erschließen und gemein- Brain Dump 
schaft-liches Verständnis dafür entwickeln Business Process and Value Maps, Concept 
Maps, Business Model Canvas 
Problemkontext strukturieren Structuring/Clustering frameworks 
Zielgruppe (Nutzer, Kunde) identifizieren und | User Profile Canvas mit 
verstehen Persona 
Jobs-to-be-done 
Gains & Pains 
Use Cases 
Zielgruppe (Nutzer, Kunde) verstehen Needfinding-Gespräch, Interview for Emp- 


athy (jeweils inkl. Vorbereitung), z. B. mit 
W-Fragen (What? How? Why? Who?) nach 
der AEIOU-Methode (Activities, Environment, 
Interaction, Objects, User) 

Empathy Map 

Future User 


Im Modell des Hasso-Plattner-Instituts umfasst „Empathize‘“ die Phasen „Verstehen“ 
und „Beobachten“. Tab. 4.4 zeigt gängige Instrumente für die in der Phase enthaltenen 
Aktivitäten. 


Define (Problemstellung definieren) 
In diesem Modus geht es darum, auf den Erkenntnissen aus dem Modus „Empathize“ 
aufzubauen, sie zu teilen und zusammenzuführen, zu strukturieren, zu gewichten und 
zu interpretieren. Diese Synthese dient dazu, die Personas für idealtypische Nutzer zu 
prüfen und weiterzuentwickeln und gegebenenfalls die Perspektiven verschiedener 
Stakeholder einzunehmen. Ergebnisse sind ein weiter vertieftes Verständnis für die 
Benutzer und den Problemraum sowie eine konkretisierte, aussagekräftige Problem- 
stellung (Design Challenge). Letztere schlägt sich in einem einzigen Satz nieder, welcher 
als sogenannter Point of View (POV) die Frage für die anschließende Phase der Ideen- 
gewinnung bildet [8, S. 73]. In der Praxis werden unterschiedliche POV-Fragen ver- 
wendet. Eine typische Formulierung ist die „How might we?“-Frage, also beispielsweise 
„Wie könnten wir [User, Kunde] helfen, [ein bestimmtes Ziel] zu erreichen?“ [8, S. 74]. 
Im Modell des Hasso-Plattner-Instituts entspricht „Define“ der Phase „Standpunkt 
definieren“. In der folgenden Tab. 4.5 sind übliche Hilfsmittel für die in der Phase ent- 
haltenen Aktivitäten aufgeführt. 


Ideate (Ideen gewinnen) 

Das Ziel der Ideengewinnung ist es einen breiten Lösungsraum zu erarbeiten, also 
möglichst viele und auch möglichst unterschiedliche Ideen zu entwickeln und zu visu- 
alisieren. Ausgangspunkt ist die Point-of-View-Frage, jedoch gehen sämtliche bisher 
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Tab. 4.5 Methoden und Werkzeuge für die Phase „Define“ 


Aktivität/Thema Ausgewählte Methoden bzw. Werkzeuge 
Erkenntnisse teilen Story share and capture (Storytelling) 
Erkenntnisse interpretieren, Schlüsse ziehen Saturate and group 

Empathy Map 


Customer/User Experience Journey (mit 

actions, mindset, touch points, pain points, 
moments of truth) 

+ 


Zielgruppe (Nutzer, Kunde) noch besser ver- Persona 

stehen Composite Character Profile 
Power of Ten 
2x2 Matrix 


Why-How-Laddering 

Point of View 

360-Grad-Betrachtung 
| A day in the life of ... 


erarbeiteten Erkenntnisse in diese Phase ein, also beispielsweise auch User Profile Can- 
vas, Empathy Map und Customer/User Experience Journey. Grundlegendes Instrument 
ist das Brainstorming, das durch Kreativitätstechniken und gezielte Aufgaben (z. B. 
Ideengenerierung zu bestimmten Funktionen) weiter und mehrfach stimuliert werden 
kann. Auch die Gestaltung erster „Low-Fidelity“-Prototypen und deren Test können wei- 
tere Denkanstöße für Lösungen liefern und Iterationen auslösen. 

Der Methodeneinsatz in diesem Modus soll dazu befähigen, über offensichtliche 
Lösungen hinauszugehen und damit das Innovationspotenzial erhöhen, indem die kol- 
lektiven Perspektiven und Stärken des Teams genutzt werden. Unerwartete Lösungs- 
richtungen sollen aufkommen können und zur Menge und Unterschiedlichkeit der 
Ideen beitragen. So entsteht eine Vielzahl von Ideen, welche sortiert, verdichtet und 
bewertet werden. Beim gesamten Vorgehen sollte streng zwischen der Generierung und 
der Bewertung der Ideen getrennt werden, um nicht früh den kreativen Flow zu einzu- 
schränken. 

Im Modell des Hasso-Plattner-Instituts entspricht „Ideate“ der Phase „Ideen finden“. 
Gängige Instrumente für die in diesem Modus enthaltenen Aktivitäten sind Tab. 4.6 zu 
entnehmen. 


Prototype (Prototypen erstellen) 

Das Prototyping greift die am höchsten bewerteten Ideen aus der Ideenentwicklung auf 
und bearbeitet sie weiter. Dabei wird der Grundsatz des Design Thinking umgesetzt, 
Sachverhalte, Produkte und Ergebnisse möglichst früh zu visualisieren und anhand greif- 
barer Modelle mit potenziellen Nutzern zu testen, zu diskutieren und mit dem erhaltenen 
Feedback weiterzuentwickeln. Prototypen werden also erzeugt, um zu lernen, offene Fra- 
gen und Unstimmigkeiten zu klären, eine Konversation bzw. einen Diskurs zu beginnen 
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Tab. 4.6 Methoden und Werkzeuge für die Phase „Ideate“ 


Aktivität/Thema | Ausgewählte Methoden bzw. Werkzeuge 


Ideen generieren (iterativ) Generelles Brainstorming auf Basis des POV (z. B. How might 
we?) mit Stimulierung durch Kreativitätstechniken 

| gezieltes Brainstorming (kritische Funktionalitäten, Bench- 
mark, Dark Horse, Funky Prototype) 

| Power of Ten, Bodystorming 


Quick & Dirty Prototyping 


Bu i | 
% z | 
Ideen sortieren, verdichten | 


Swap Sort, 2 x 2 Matrix 
| Concept-/Systems-/Mind-Maps, Ideensteckbriefe 


Ideen bewerten und priorisieren Vier-Kategorien-Methode; Post-it- Voting, Spend your budget 


und schnell und noch günstig Sackgassen zu erkennen. Neben der Veränderung kann das 
Feedback auch zum kompletten Verwerfen und damit zu einer grundlegenden Iteration 
in weiter zurückliegenden Phasen führen. Dieses Vorgehen wird auch mit dem Slogan 
„Love it, change it or leave it“ umschrieben. 

Prototyping transferiert Ideen aus dem Kopf in die physische Welt. Ein Prototyp kann 
demnach alles sein, was eine physische Form annimmt und der Maxime „don’t tell me, 
show me!“ folgt: eine Wand mit Post-it-Notizen, ein Rollenspiel, ein Raum, ein Objekt, 
ein Storyboard oder auch beliebige Kombinationen verschiedener Ausdrucksmittel. 

Die Granularität des Prototyps sollte dem Projektfortschritt entsprechen. In den frü- 
hen Stadien eines Projektes sollten Prototypen entstehen, die schnell anzufertigen und 
kostengünstig sind (Low Fidelity, Quick & Dirty), aber schon nützliches Feedback von 
Benutzern und Kollegen hervorrufen. In späteren Stadien sollten die Prototypen ver- 
feinert werden und bestimmte Fragestellungen eingehend untersuchen lassen. Sie dienen 
dazu, Empathie zu vertiefen, zu testen, weitere Ideen und Inspiration zu gewinnen. 

Im Modell des Hasso-Plattner-Instituts entspricht „Prototype“ der Phase „Prototyp 
entwickeln“. Die folgende Tab. 4.7 zeigt gängige Instrumente für die in dieser Phase ent- 
haltenen Aktivitäten. 


Test (Prototypen testen) 
Wie im vorherigen Abschnitt bereits ausgeführt, ist Testen eng mit Prototyping ver- 
knüpft. Die Empfehlung „Prototype as if you know you’re right, but test as if you know 
you’re wrong.“ beschreibt eine Denkhaltung, welche diesen Zusammenhang verdeut- 
licht. Testen bietet die Chance, qualitatives Feedback zu den prototypischen Lösungen zu 
erhalten, sie besser zu machen, weiter über die Nutzer zu lernen und damit die Empathie 
für sie zu vertiefen. Der Testmodus ist ein iterativer Lernmodus, in dem die Prototypen 
in den Kontext des potenziellen Benutzers gestellt und von diesem benutzt und bewertet 
werden. Wichtige Prinzipien dabei sind: Zeigen und nicht reden, Erlebnisse schaffen und 
dem Benutzer Vergleiche ermöglichen. 

Das Feedback bei den Tests kann nicht nur zu Veränderungen, sondern auch zum kom- 
pletten Verwerfen und damit zu einer grundlegenden Iteration über weiter zurückliegende 
Phasen führen. Dieses Vorgehen wird auch mit dem Slogan „Love it, change it, or leave 
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Tab. 4.7 Methoden und Werkzeuge für die Phase „Prototype“ 


Aktivität/Thema | Ausgewählte Methoden bzw. Werkzeuge 


Prototypen erstellen Low-Fidelity-Prototypen z. B. aus Bastelmaterial (Lego, Knetmasse etc.) 
Rollenspiele, Storytelling, Storyboards 
Wireframes, Screen-Design-Tools 
Shooting and editing video 


P Aktivitä/Thema | Ausgewählte Methoden bzw. Werkzeuge 
er Muri Phrase Feedback einholen | Feedback Grid 


„I like, I wish, What if?“ 
A/B-Tests mit digitalen Tools 


it“ umschrieben [8, S. 34]. Prinzipiell ist bei jeder Iterationsschleife unabhängig von 
deren Umfang zu reflektieren, welche vorherigen Ergebnisse (z. B. Personas, User/Custo- 
mer Experience Journey) aufgrund des Feedbacks angepasst werden müssen. 

Im Modell des Hasso-Plattner-Instituts entspricht „Test“ der Phase „Testen“. Tab. 4.8 
enthält Instrumente für die in der Phase ausgeführten Aktivitäten. 


4.3.2.3 Place 

Für die Arbeit der interdisziplinären Teams in den beschriebenen Modi gilt es eine Kreativi- 
tät fördernde Umgebung, sogenannte Make oder Creative Spaces, zu schaffen. Dies bezieht 
sich insbesondere auf die Verfügbarkeit, Größe und Einrichtung von Räumlichkeiten als 
auch auf Hilfsmittel und Materialien für Visualisierung und Prototypengestaltung. Es geht 
vor allem darum, den Teams, frei und dauerhaft verfügbare Arbeits-, Interaktions-, Entspan- 
nungs- und Lagerbereiche, flexible Möbel mit Rollen, beschreib- und abwischbare Flächen 
(Wände, Tische, Tafeln), sowie gute und schnelle Zugänge zu Informationen (Internet, 
Bibliotheken etc.), Werkzeugen, Arbeitsmaterialien und Verpflegung bereitzustellen [7, 
S. 216 ff.]. Auch Beleuchtung, Belüftung und Klimatisierung sind wichtige Rahmen- 
bedingungen. 

In der Praxis räumt man vor allem bei länger andauernden Projekten den Teams 
mitunter auch die Möglichkeit ein, die Umgebung selbst zu gestalten (z. B. Möbel 
selbst bauen). Doorley und Witthoft haben Anleitungen und Erfahrungen u.a. bei der 
Gestaltung von Kreativitätsumgebungen für die d.school publiziert [10]. 


4.4 Verbindung der Konzepte 
4.4.1 Überblick 


Wie gezeigt zielt Design Thinking auf die Innovation von Produkten und Services, 
Geschäftsmodellen und -prozessen ab. Im Mittelpunkt stehen Benutzerzentriertheit, 
Kreativität und Agilität in einem experimentellen, iterativen Prozess, den interdiszipli- 
näre Teams durchlaufen. 
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Das Prozessmanagement verfolgt mit der agilen und kreativen Prozessneu- oder 
-umgestaltung unter Berücksichtigung von Kundenbedürfnissen eine vergleichbare Ziel- 
setzung. Im Folgenden stellen wir Bezüge zwischen den Konzepten her und diskutieren 
die Erfolg versprechende Nutzung von Design-Thinking-Elementen für das Prozess- 
management. 

Wir legen dabei besonderes Augenmerk auf die Digitalisierung von Prozessen, das 
heißt auf den sinnvollen Einsatz von Informations- und Kommunikationstechnik für die 
Prozessverbesserung und -innovation. Prototypen und endgültige Lösungen sind damit 
immer Workflow-Anwendungen unterschiedlichen Automatisierungsgrades. 


4.4.2 Benutzerzentriertheit 


Traditionelle BPM-Ansätze beziehen zwar bei der Prozessanalyse in der Regel die 
Beteiligten mit Interviews und Workshops ein. Im Vordergrund der aktivitäts- und 
ablaufbezogenen Interviewfragen, Kartenabfragen oder Beobachtungen stehen dabei 
jedoch die „harten“ Fakten der Arbeit im Prozess mit den in Abschn. 4.2.2 aufgeführten 
Merkmalen. Aspekte wie das Verstehen von Motivation, Denkweisen und Werten der 
Benutzer, die für die Entwicklung von Empathie im Design Thinking ausdrücklich 
betont werden, bleiben hier weitgehend unberücksichtigt. Daran haben auch neuere Kon- 
zepte wie Social BPM bisher wenig geändert. 

Eine interessante Brücke kann der Ansatz des Subjektorientierten Business Process 
Management (S-BPM) schlagen, das bereits zu Beginn dieses Kapitels im Fallbeispiel 
verwendet wurde. Er stellt die Subjekte als Handelnde im Prozess in den Mittelpunkt 
der Betrachtung. Mit der dazugehörigen Methodik und Sprache (vgl. Abschn. 3.6) sowie 
geeigneten Werkzeugumgebungen können Vertreter von am Prozess beteiligten Subjek- 
ten nicht nur als Befragte oder Beobachtete, sondern als aktive Designer an der iterativen 
Lösungsentwicklung mitwirken. Sie spezifizieren dabei nicht nur explizit das Verhalten 
des von ihnen repräsentierten Subjekts und dessen Interaktionen mit anderen Beteiligten, 
sondern können durch die Ausführung des resultierenden Modells sofort das Ergebnis 
ihrer Gestaltung erproben und verändern. Bei all dem können sie implizit auch die oben 
angesprochenen „weichen“ Faktoren einbringen. 


4.4.3 Agiler Prozess mit Iterationen 


Umfangreichere Prozessmanagementvorhaben werden in der Praxis häufig nach wie vor 
mit traditionellen Projektmanagementmethoden in klar definierten Phasen mit Meilen- 
steinen durchgeführt, vergleichbar dem Wasserfallmodell bei der Softwareentwicklung. 
Dies bedeutet, dass der Weg von der Analyse über die Gestaltung des fachlichen 
Modells und dessen organisatorische und informationstechnische Umsetzung bis zu 
einer lauffähigen Workflow-Anwendung viel Zeit in Anspruch nimmt. Außerdem steigt 
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damit die Wahrscheinlichkeit, dass die IT-Lösung von den sich weiterentwickelnden 
Bedürfnissen und Wünschen der Benutzer abweicht. 

Insbesondere für die Prozessdigitalisierung ist es deshalb von Vorteil den agilen, ite- 
rativen Prozess des Design Thinking zu adaptieren. Dies eröffnet die Möglichkeit der 
steigenden Dynamik hinsichtlich der Entstehung neuer Prozesse und der Veränderungen 
bestehender Vorgänge, etwa aufgrund neuer oder geänderter Geschäftsmodelle wie 
Servitization, gerecht zu werden. Für die weiteren Überlegungen stellen wir die Modi 
des Design Thinking den Aktivitätsbündeln im Prozessmanagement gegenüber (vgl. 
Abb. 4.7). 

In Verbindung mit den Ausführungen in Abschn. 4.2.2 und 4.3.2.2 zeigt die 
Abbildung, dass DT stärker zwischen Problemverständnis und Lösungsgestaltung trennt. 
Letztere beginnt erst mit Ideate. Davor wird ausgiebig die Ist-Situation beleuchtet und 
beispielsweise auf dem Weg über Personas in der Customer/User Experience Journey 
dokumentiert und visualisiert, ehe mit der Point-of-View-Fragestellung der Ausgangs- 
punkt für die Ideengenerierung formuliert wird. 

Beim Prozessmanagement ist die Problemstellung dagegen in der Regel bereits zu 
Beginn klar formuliert. Bei der Erneuerung bestehender Prozesse leitet sie sich meist aus 
dem Wunsch nach verbesserter Prozess-performance ab (z. B. Durchlaufzeitverkürzung). 
In der Praxis werden deshalb meist nur diesbezügliche Schwachstellen des Ist-Zu- 
stands dokumentiert und Analyseinformation genutzt, um, wie auch bei einem neuen 
Prozess, gleich ein neues Soll-Modell zu entwickeln und zu visualisieren. Der kreative, 
gestalterische Teil beginnt damit früher als beim Design Thinking und ist tendenziell mit 
weniger Information als Ausgangsbasis unterfüttert. Er ist stärker analytisch (z. B. durch 
Performance Indicators) getrieben als durch die im Rahmen der Empathieentwicklung 
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Abb. 4.7 Zuordnung von Design-Thinking-Modi und BPM-Aktivitätsbündeln 
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im Design Thinking identifizierten „weichen“ Faktoren. Unabhängig von der etwas 
unterschiedlichen konkreten Ausgestaltung lässt sich das Aktivitätsbündel Analyse & 
Modellierung den DT-Modi Empathize, Define und Ideate zuordnen. 

Für eine umfassendere Erfassung des Problemkontextes und die dadurch erzielbare 
Ausweitung des Lösungsspektrums für die Prozessinnovation bietet sich der Einsatz 
bewährter DT-Instrumente an. Insbesondere bei der Entwicklung eines neuen Prozesses 
können die Teammitglieder z. B. mit einem Brain Dump zum Problemumfeld und der 
Diskussion der Ergebnisse ihren Betrachtungshorizont erweitern und ein gemeinsames 
Verständnis entwickeln. 

Mithilfe von Personas für die Prozessbeteiligten in ihren jeweiligen Rollen sowie 
mit Interviews und Beobachtungen lassen sich Customer/User Experience Journeys 
beschreiben. 

Sind Mitwirkende am Prozess selbst Teammitglieder können diese selbst ihre 
Erfahrungen ebenfalls als Journey visualisieren. Damit erweitert sich die Informations- 
basis über die klassischen, objektiven Prozesscharakteristika hinaus um die Perspektive 
der Nutzer. Dieses breitere Fundament für das Entwickeln von Lösungsideen sollte den 
höheren Aufwand rechtfertigen. 

In Abschn. 4.2.2 haben wir dargelegt, dass bereits bei der Analyse und Modellierung 
von Prozessen Überlegungen zur Effektivität und Effizienz zumindest von Modellteilen 
angestellt werden. Dies gilt insbesondere, wenn die späteren Anwender dies wie bei der 
Subjektorientierung selbst tun. Deshalb sind die Aktivitätsbündel Validierung und Opti- 
mierung dem DT-Modus Test zugeordnet, erstrecken sich aber auch über Empathize, 
Define und Ideate. 

Mit dem Fokus auf Prozessdigitalisierung entspricht dem Modus Prototype beim 
Prozessmanagement das Aktivitätsbündel der IT-Implementierung. Das Prototyping im 
Design Thinking erhebt den Anspruch schnell und mit einfachen Mitteln, mithin kosten- 
günstig, einen vorführbaren Prototyp zu erzeugen, um rasch Feedback vom Benutzer 
einzuholen (Modus Test) und dieses zu verwerten. Mit der Übertragung dieses „fail 
early, fail often“-Prinzips auf das Prozessmanagement muss das Team in die Lage ver- 
setzt werden, das Modell mit geringem Aufwand ausführbar zu machen. Im Vordergrund 
steht also die Erzeugung eines funktionalen Prototyps in Form von Software, der die 
Anwender erfahren und erleben lässt, wie ihre Arbeit mit der IT-Lösung aussehen würde. 

Die Zuordnung zur IT-Implementierung sollte aber für den Prototyp nicht Program- 
mierung bedeuten. Vielmehr muss es im Sinne der schnellen Iterationen möglich sein, 
den Prototyp aus dem Modell automatisch zu generieren und im Aktivitätsbündel Vali- 
dierung die Nutzer erproben zu lassen. Anschließende Modelländerungen aufgrund 
des Feedbacks führen auf demselben Weg zu einem neuen Prototyp, so lange, bis eine 
Version gefunden ist, welche die Anwender zufriedenstellt. Solch Kostengünstiges und 
frühzeitiges Prototyping verhindert möglicherweise aufwendigere Nacharbeiten bei 
der späteren Realisierung der echten Laufzeitumgebung. Mit einer vergleichbaren Vor- 
gehensweise kann das Design der Benutzungsschnittstelle nach den Prinzipien des User 
Experience Design erfolgen. 
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Da das jeweilige Prozessmodell ja nicht nur die Basis für Prototypen, sondern in sei- 
ner letztlich verabschiedeten Version auch für die angestrebte Workflow-Anwendung 
ist, umfasst das Aktivitätsbündel IT-Implementierung auch deren Realisierung in 
der in Abschn. 4.2.6 beschriebenen Weise. Wenn dafür über die modellbasierte Work- 
flow-Steuerung hinausgehende Software entwickelt werden muss, bietet sich im Sinne der 
benutzerzentrierten, agilen Vorgehensweise SCRUM als Software-Entwicklungsmethode an. 

Im Zusammenhang mit der IT-Implementierung gilt es auch zu entscheiden, 
inwieweit man die von Software-Start-ups oft verwendete Strategie der Minimum Viable 
Products verfolgen möchte. Dies würde bedeuten, Software mit minimaler Funktion den 
Kunden bzw. Anwendern nicht nur prototypisch, sondern auch produktiv zur Verfügung 
zu stellen, um deren Feedback für die Weiterentwicklung einzuholen. Bei IT-Lösungen 
für geschäftskritische Prozesse Könnte dies riskant sein, anderseits kann es durch frühe 
Gewöhnung von Kunden an Features möglicherweise einen Vorsprung gegenüber Mit- 
bewerbern eröffnen. 

Wie in Abschn. 4.2.5 und 4.2.7 erläutert, ist das Modell auch in die Organisation ein- 
zubetten (Organisatorische Implementierung), ehe der Prozess produktiv gesetzt wer- 
den kann (Betrieb & Monitoring). 

Im Design Thinking folgen vergleichbare Schritte für die Implementierung z. B. eines 
Produkts auf Basis eines akzeptierten Prototyps, sowie für die Nutzung, die jedoch nicht 
mehr zu den Modi im engeren Sinn zählen (gepunktete Formen in Abb. 4.7). 


Fazit 

Um den Anforderungen der Digitalisierung von Prozessen gerecht zu werden sollte 
ein Prozessmanagementvorgehen Design-Thinking- und Prozessmanagementkonzepte 
kombinieren. 

Es muss geeignet sein, Prozesse und deren Änderungen rasch sowohl fachlich als 
auch in der IT abzubilden und dabei in kurzen Iterationszyklen die Anwender adäquat 
einzubinden, um die entstehende Lösung deren Vorstellungen anzunähern. 

Neben den für die Design-Thinking-Modi Empathize, Define und Ideate nutzbaren 
Instrumente sind dafür insbesondere einfach handhabbare Methoden und Werkzeuge 
nötig, mit denen das Team und/oder die Prozessbeteiligten selbst 


1. individuell unterschiedliche mentale Modelle der Arbeit artikulieren können 

2. diese verschiedenen mentalen Modelle harmonisieren können 

3. daraus Lösungsideen und konkrete Lösungsvorschläge in Form von Modellen ent- 
wickeln können 

4. diese Modelle automatisch in ausführbare Prototypen überführen und testen können 

5. freigegebene Modelle mit begrenztem Aufwand in Workflow-Anwendungen für 
den Live-Betrieb überführen können 


Ein Beispiel für ein Konzept zur Unterstützung von 1) und 2) ist Compare/WP 
(vgl. Abschn. 5.1.2). Die Anforderungen 3), 4) und 5) werden beispielsweise vom 
S-BPM-Ansatz und darauf basierenden BPM-Tools abgedeckt [11, 12]. 
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4.4.4 Interdisziplinäres Team 


Die Bedeutung der Interdisziplinarität des von einem Facilitator begleiteten Teams beim 
Design Thinking haben wir im Abschn. 4.3.2.1 ausgeführt. 

Auch BPM-Projekte werden üblicherweise von Teams durchgeführt. Wir unter- 
scheiden dabei vier Rollen: 


Governors (Treiber und Verantwortliche) setzen die Rahmenbedingungen. Diese 
umfassen im Wesentlichen den Betrachtungsbereich (Scope), also die Abgrenzung des 
im Projekt bearbeiteten Prozesssystems sowie, konkret auf die Analyse und Modellie- 
rung bezogen, die Methodik und die Werkzeuge. 


Actors (Arbeitshandelnde) sind die gegenwärtigen oder zukünftigen Akteure, welche 
die im zu verändernden oder zu entwickelnden Prozess zur Laufzeit die Aktionen in den 
Instanzen ausführen. Sie sind demnach die Träger konkreten ausführungsbezogenen 
Prozesswissens für ihren Anteil an der Erstellung des Prozessergebnisses, wissen also 
welche Teilschritte sie in welcher Reihenfolge erledigen, welche Informationen und 
Hilfsmittel sie dazu benötigen und mit wem sie dafür interagieren. 


Experts (Spezialisten) unterstützen die anderen Rollen mit methodischem und fach- 
lichem Wissen. Es sind beispielsweise Domänenexperten, die im betreffenden Fach- 
gebiet über Expertise verfügen und einbringen können, welche über die der Actors 
hinausgeht. Methodenexperten helfen den Beteiligten, insbesondere den Actors, bei der 
Artikulation und Harmonisierung ihrer mentalen Modelle sowie bei der Umsetzung mit 
einer der in Kap. 3 vorgestellten Modellierungssprachen. Für die technische Implemen- 
tierung der fachlichen Modelle werden schließlich IT-Experten hinzugezogen. Exper- 
ten in den unterschiedlichen Feldern werden bei Bedarf auch von außerhalb der eigenen 
Organisation als externe Berater involviert. 


Facilitators (Entwicklungsbegleiter) moderieren und koordinieren das Vorgehen 
und die Zusammenarbeit der Beteiligten. Sie sorgen beispielsweise dafür, dass Actors 
die Schnittstellen zwischen ihren Arbeitsschritten abstimmen und identifizieren für 
besondere Problemstellungen bei Bedarf geeignete Experten und binden sie ein. Bei all- 
dem motivieren und überprüfen die Facilitators die Einhaltung der von den Governors 
gesetzten Rahmenbedingungen. 

Beim traditionellen phasenorientierten Vorgehen im BPM wirken bei Analyse, Model- 
lierung, Validierung und Optimierung unter der Projektleitung als Facilitator zunächst 
meist Actors und Experts als fachliche Inputgeber und Methodenexperten zusammen. 
Die Implementierung der verabschiedeten fachlichen Modelle übernehmen dann 
IT-Experten. Als Nachteile dieses Vorgehens haben wir bereits in Abschn. 4.4.3 die mit- 
unter lange Dauer und dadurch bedingte Abweichung von den Bedürfnissen der Stake- 
holder identifiziert. 
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Seit einiger Zeit verbreitet sich deshalb der BizDevOps-Ansatz, der den im Zuge der 
Digitalisierung steigenden Agilitätsanforderungen Rechnung tragen will. Er strebt eine 
vergleichsweise engere Verzahnung von Fachabteilung (Business, Biz), IT-Entwicklung 
(Development) und IT-Betrieb (IT Operations) an?. Dem agilen Team gehören von Beginn 
an Vertreter aller Bereiche in den beschriebenen Rollen an, welche die Prozesslösung 
gemeinsam gestalten. Das Konzept kann damit sowohl das Business-IT-Alignment ver- 
bessern als auch das Enabling durch IT fördern. Ersteres bedeutet, dass der Abdeckungs- 
grad der Bedürfnisse der Fachabteilungen durch passende IT-Services steigt. Beim 
Enabling gibt die IT Impulse für die Nutzung von Informations- und Kommunikations- 
technik für Geschäftsmodell- und Geschäftsprozessinnovationen. 

Wie das Design Thinking sieht der BizDevOps-Ansatz also ein interdisziplinäres 
Team vor. Herausforderung ist es in solchen Teams, das „Wir“-Denken unter „T-shaped“ 
Personen zu etablieren. Dies liegt daran, dass Linieneinheiten, denen die Beteiligten 
entstammen (verschiedene am Prozess beteiligte Fachabteilungen, IT-Entwicklung, 
IT-Betrieb), unterschiedliche Ziele verfolgen und diesen oft tendenziell höhere Priorität 
einräumen als einem gemeinschaftlich zu erreichenden Ziel (innovative oder verbesserte 
Prozesslösung). Hinzu kommt, dass die Kreativität möglicherweise durch Involvierung 
der fachlichen Domänenexperten behindert wird. 

Einerseits kennen Prozessbeteiligte oft Schwachstellen existierender Prozesse und 
Lösungsvorschläge dafür. Andererseits sind sie eventuell „betriebsblind“ und in der 
Betrachtung des Problem- und insbesondere des Lösungsraums zu eingeschränkt. Bei der 
Rekrutierung sollten demnach nicht nur Diversitätsaspekte wie Geschlecht, Alter und kul- 
tureller Hintergrund eine Rolle spielen. Vielmehr ist auf eine sinnvolle Balance zwischen 
Domänenexperten und Teammitgliedern zu achten, die themenfremde fachliche Hinter- 
gründe aufweisen und kein ausgeprägtes Eigeninteresse am Aussehen einer Lösung haben. 

Die Schwerpunktverschiebung kann man davon abhängig machen, ob das Ziel eher 
eine Prozessverbesserung ist, bei der Erfahrungen und Inputs der mit dem bestehenden 
Prozess vertrauten Personen hilfreich sein können. Steht dagegen eine radikalere 
Prozessinnovation im Vordergrund, könnten diese möglicherweise eher limitierend wir- 
ken. Selbstverständlich sollten auch bei der ursprünglichen Zielsetzung der Verbesserung 
Ideen für eine fundamentale Innovation des betrachteten Prozesses nicht außer Acht 
gelassen werden. 


?Bei der Betrachtung über Unternehmensgrenzen hinweg könnte man noch Partner im Wert- 
schöpfungsnetzwerk ergänzen wie Lieferanten, Kunden oder Logistikdienstleister (Network Part- 
ners) und sinngemäß von NetBizDevOps sprechen. 
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Vorbereitung der 
Prozessimplementierung 


Ziel der Prozessvorbereitung im Sinne einer nachfolgenden Implementierung ist eine 
präzise Spezifikation von Prozessen mit der Beschreibung der Prozessstrategie und der 
Prozesslogik. Die Vorbereitung umfasst die Aktivitätsbündel auf der rechten Seite des 
offenen Zyklus, dies sind die Analyse, die Modellierung, die Validierung und die Optimie- 
rung (siehe Abb. 5.1). Das Ergebnis dieser Aktivitätsbündel ist eine Prozessbeschreibung, 
die präzise genug für die Umsetzung ist. Die Vorbereitung teilt sich in die Aktivitäten 
Analyse mit Modellierung, Validierung und Optimierung auf. Diese Aktivitäten wer- 
den nicht in einer strengen Reihenfolge durchgeführt, sondern die jeweiligen Tätigkeits- 
schwerpunkte können zwischen den Aktivitäten häufig wechseln. Die Abbildung zeigt die 
Einordnung der Vorbereitung in das gesamte Prozessmanagementmodell. 

In den folgenden Abschnitten werden ausgewählte Methoden für diese Aktivitäts- 
bündel vorgestellt. 


5.1 Analyse und Modellierung 


Analyse und Modellbildung kann nicht scharf getrennt werden. Schwerpunkt der Ana- 
lyse sind die strategischen Aspekte von Prozessen, während in der Modellierung auf die 
Prozesslogik fokussiert wird. In der Analyse wird also der Anfang, mit dem zugehörigen 
Input, das Ende mit dem erzeugten Output und das damit befriedigte Kundenbedürfnis 
klargelegt. In der Analyse werden auch der Rahmen und die wesentlichen Aspekte der 
Prozesslogik abgesteckt. 

In der Praxis wird allerdings bei der Überarbeitung von Prozessen in dieser Phase 
kaum die Prozesslogik des Ist-Zustands explizit beschrieben. Die Analyse der aktuellen 
Prozesslogik erfolgt im Rahmen der Definition des gewünschten Sollprozesses. Der aus- 
schließliche Bezug zur Ist-Situation macht in der Regel wenig Sinn und ist auch für alle 
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Abb. 5.1 Einordnung Vorbereitung 
der Vorbereitung in das 
Prozessmanagementmodell 


Org. 
Implemen- 
tierung 


Validierung 


Analyse & 
Model- 
lierung 


Betrieb und 
Monitoring 


IT- 
Implemen- 
tierung 


< Situative Abfolgen und Iterationen > 


Beteiligten zumeist unangenehm zu dokumentieren — Was wurde in letzter Zeit „falsch“ 
gemacht? 

Solange man das Werkzeug ‚natürliche Sprache‘ benutzt, befindet man sich eher 
in der Aktivität Analyse als Modellierung. Der Übergang von der natürlichen Spra- 
che zu einer formaleren Prozessmodellierungssprache entspricht dem Übergang in 
Modellierungsaktivitäten. Der Modellierung kann eine mehr oder weniger intensive Ana- 
lysemethode vorausgehen. In Extremfällen wird unmittelbar ein Prozessmodell ohne 
vorangehende natürlich sprachliche Analyse erstellt. Allerdings ist zu empfehlen, dass 
zumindest die strategischen Aspekte des betrachteten Prozesses bekannt und definiert 
sind. 

In der Folge werden Richtlinien zur Artikulation und Abstimmung von prozess- 
relevantem Wissen vorgestellt, welche methodisch und werkzeugtechnisch unterstützt 
werden können. Ein wesentliches Element stellt dabei das Verständnis von Rollen dar, 
welche die Beteiligten als relevant für die Abwicklung von Prozessen erachten. Darüber 
hinaus empfiehlt sich, die Austauchbeziehungen zwischen Akteuren zu betrachten, zur 
weiteren Gestaltung von Prozessen deren Qualität zu bewerten und daraus gegebenen- 
falls Änderungspotenzial abzuleiten. 


Optimierung 


5.1.1 Allgemeines zu Artikulation und Abstimmung 


Wissen über Arbeitsabläufe und organisationale Prozesse ruht in den meisten Fällen in 
den Köpfen von Handlungsträgern. Daher kommt einer kontextsensitiven strukturierten 
Erhebung und Analyse entscheidende Bedeutung zu. Die Erhebung dient der Artikula- 
tion von Erfahrungswissen und wird in den meisten Fällen im Rahmen der Modellierung 
durchgeführt. Wird sie allerdings bereits vorab bearbeitet, dann kann in GPM-Projek- 
ten mit der Vielfalt von Ansätzen zur Aufgaben- oder Problembewältigung strukturier- 
ter umgegangen werden. Allerdings spielen in diesem Zusammenhang die Abstimmung 
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und der Abgleich unterschiedlicher Ansätze eine wesentliche Rolle. Deren Unterstützung 
trägt wesentlich zu einer integrationsfähigen Lösungsbildung trotz hoher Vielfalt und 
individueller Zugänge zur Aufgabenerfüllung bei. In diesem Abschnitt wird daher auf 
die Erhebungs- und Aushandlungsmethoden sowie Instrumente eingegangen, welche 
Individuen Artikulation im Rahmen kollektiver Reflexions- und Aushandlungsprozesse 
ermöglicht. 

Wie Menschen ihre Arbeit durchführen, wie sie auf Vorgaben oder Abweichungen 
reagieren und wie sie mit anderen kooperieren, wird wesentlich von ihrer Wahrnehmung 
der organisationalen Realität geprägt. Die Interpretation der wahrgenommenen Rahmen- 
bedingungen sowie die Ableitung der als adäquat erachteten Reaktion von Akteuren kann 
mit der kognitionswissenschaftlichen Theorie der mentalen Modelle erklärt werden. 
Diese Theorie kann auch als Grundlage verwendet werden, um von den operativ tätigen 
Personen ausgehende Lern- und Veränderungsprozesse in Organisationen zu erklären. In 
diesem Abschnitt bildet sie deshalb die Grundlage für die Ableitung von Maßnahmen, 
die Arbeitende in die Lage versetzen sollen, sich ihrer Arbeitsabläufe und der diese prä- 
genden organisationalen Zusammenhänge und Rahmenbedingungen bewusst zu werden. 

Das Konzept der „mentalen Modelle“ wird verwendet, um zu erklären „wie Men- 
schen die Welt verstehen — genauer: wie sie ihr Wissen benutzen, um sich bestimmte 
Phänomene der Welt subjektiv plausibel zu machen [1]“. Mentale Modelle sind dabei 
Erklärungsmodelle der Welt, die von Menschen auf Basis von Alltagserfahrungen, bis- 
herigem Wissen und darauf basierenden Schlussfolgerungen gebildet werden. Ein men- 
tales Modell wird vom jeweiligen Individuum als Basis verwendet, um die Welt zu 
verstehen und gegebenenfalls Vorhersagen über deren Verhalten zu bilden [1]. 

Das mentale Modelle prägende Wissen kann auf Alltagserfahrung basieren oder durch 
Vermittlung oder Instruktion begründet werden. Die Modifikation und Erweiterung der 
eigenen Wissensbasen und die (Weiter-) Entwicklung der kognitiven Fähigkeiten, die 
für die Ableitung von Schlussfolgerungen notwendig sind, bezeichnet Seel als „Lernen“. 
Lernen ist „mit der Verarbeitung individueller Erfahrungen mit sowie vermittelter Infor- 
mation über die Welt, ihre Struktur und Evidenz verbunden und kann als ein Prozess per- 
manenter konzeptueller Veränderungen verstanden werden.“[1] Lernen setzt damit die 
Fähigkeit und Bereitschaft voraus, „vermittelte Weltauffassungen zu verstehen, zu akzep- 
tieren und sodann den eigenen gedanklichen Konstruktionen zugrunde zu legen“[1]. 

Die Veränderung mentaler Modelle über Arbeitsprozesse weist zwei grundlegende 
Schwierigkeiten auf. Bei bereits als nicht adäquat erkannten mentalen Modellen besteht 
grundsätzlich die Bereitschaft zur Veränderung (im Sinne einer Anpassung des menta- 
len Modells an die als verändert wahrgenommene Umweltbedingungen), die Heraus- 
forderung besteht allerdings darin, an die notwendige Information zu gelangen und 
adäquat dargeboten zu bekommen. Eine weitere Schwierigkeit ergibt sich in Situatio- 
nen, in denen nicht alle involvierten Individuen die Situation als „problematisch“ wahr- 
nehmen und deshalb keine grundlegende Bereitschaft zeigen, ihre der Arbeit zugrunde 
liegenden Annahmen (also ihre mentalen Modelle) zu verändern. Dies tritt vor allem 
in Situationen auf, in denen die kollaborative Reflexion nicht aus einer allgemein 
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wahrgenommenen Problemsituation heraus durchgeführt, sondern entweder mit rein 
planendem Charakter angestoßen wird, oder welche nur von einzelnen beteiligten Indivi- 
duen als „problematisch“ wahrgenommen werden. 

Diesen Problemen kann mit einer expliziten Unterstützung des Reflexionsprozesses 
begegnet werden. Eine derartige Unterstützung muss sicherstellen, dass Artefakte zur 
Repräsentation der individuellen mentalen Modelle geschaffen werden, die dann die 
Grundlage für die gegenseitige Verständlichmachung der jeweiligen Sichten auf den 
Arbeitsprozess bedienen kann. Derartige Artefakte können dazu dienen, Aspekte eines 
Arbeitsprozesses abzustimmen und sicherzustellen, dass die in Artefakten kodierte osten- 
sive Sicht auf einen Arbeitsprozess durch darauf aufbauendes performatives subjektives 
Handlungswissen in der Arbeitspraxis umgesetzt werden kann. Aus methodischer Sicht 
muss dazu sichergestellt werden, dass alle am realen Arbeitsprozess beteiligten Personen 
organisatorisch und methodisch in der Lage sind, sich am kollaborativen Lernprozess zu 
beteiligen. Dies bedingt vor allem, dass sie die verwendeten Ausdrucksformen verstehen 
und aktiv einsetzen können. Dies ist wiederum eine Lernherausforderung, die explizit 
adressiert werden muss. 

Eine in den Bildungswissenschaften weithin akzeptierte Möglichkeit zur Externali- 
sierung und Abstimmung mentaler Modelle ist die Bildung konzeptioneller Modelle. 
Gleichzeitig können derartige Modelle die Grundlage für die Spezifikation von Arbeits- 
prozessen und die Konfiguration von Arbeitsunterstützungssystemen bilden, sofern sie 
sich einer formal spezifizierten Semantik bedienen (wie etwa die BPMN oder S-BPM). 
Konzeptionelle Modelle stellen also ein Mittel dar, Arbeitende in die Lage zu versetzen, 
ihre Arbeit zu reflektieren, abzustimmen, die Ergebnisse dieser Abstimmungsprozesse 
für die Dritte zugänglich zu machen und diese im Rahmen der existierenden System- 
grenzen zur Unterstützung der eigenen Arbeitsabläufe nutzbar zu machen. 

Modelle sind Abbildungen der Realität, die zu einem bestimmten Zweck gebildet 
werden. Modelle repräsentieren nie das reale Phänomen als Ganzes, sondern enthalten 
nur jene Aspekte der Realität, die vom Modellbildenden als relevant für die jeweilige 
Zielerreichung erachtet werden. Für die Modellbildung stellt sich damit die Frage nach 
der Definitionsmacht dieser Modelle und der durch sie abgebildeten sozialen Realität. 
Sofern ein Modell nicht nur einen das modellbildende Individuum betreffenden Zweck 
erfüllt, sondern von anderen Personen genutzt wird, beeinflusst das Modell die mentalen 
Modelle dieser Personen und damit auch deren Verhalten. 

Die aktive Involvierung operativ Tätiger in die Spezifikation von Arbeitsprozessen 
stellt deshalb eine Möglichkeit für deren selbstermächtigte Gestaltung ihrer Arbeit dar. 
Dazu ist es jedoch notwendig, dass operativ Tätige in die Lage versetzt werden, der- 
artige Modelle zu verstehen, selbst zu gestalten, und deren Wirkung auf ihre Arbeits- 
prozesse abschätzen zu können. In aktuellen Ansätzen wird hingegen nach wie vor 
von der Notwendigkeit eines Prozess-Analysten ausgegangen, der die Sichtweisen der 
Arbeitenden in ein Prozessmodell übersetzt. Dies kann zu Abweichungen zwischen 
dem realen Arbeitsprozess und dessen Modellrepräsentation führen. Außerdem nimmt 
diese Vorgehensweise den operativ tätigen Personen die Möglichkeit im Sinne des 
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modellbasierten Lernens ihre mentalen Modelle zu schärfen und mit jenen der anderen 
Beteiligten abzustimmen. 

Um operativ Tätige in die Lage zu versetzen, derartige Modelle zu verstehen, muss 
das Erlernen von grundlegenden Ansätzen zur Erstellung und Interpretation konzeptio- 
neller Modelle Gegenstand der Aus- oder Weiterbildung sein. Arbeitende müssen jene 
Modelle erkennen können, die den Systemen zugrunde liegen, in die sie eingebettet sind. 
Darüber hinaus sollen sie die Implikationen von externen oder selbst durchgeführten 
Änderungen an diesen Modellen abschätzen und Interventionen dementsprechend planen 
können. 

Dazu müssen folgende Punkte methodisch unterstützt werden: 


e die Ermöglichung der individuellen Artikulation eigener mentaler Modelle über 
Arbeit, um eine individuelle Reflexion zu ermöglichen und dadurch Lücken und 
Inkonsistenzen individuell wahrnehmbar zu machen, sowie zu verhindern, dass Sicht- 
weisen einzelner Personen nicht berücksichtigt werden und diese in der Folge keinen 
Bezug zu ihrer Arbeitsrealität herstellen können 

e die Unterstützung der Vereinbarung eines gemeinsamen Vokabulars, um unterschied- 
liche Verständnisse von Begriffen zu identifizieren und sich in der Folge eindeutig 
über die gegenständliche Arbeit austauschen zu können, und zu verhindern, dass das 
gleiche reale Phänomen mit unterschiedlichen Begriffen bezeichnet wird — oder dass 
umgekehrt der gleiche Begriff für unterschiedliche reale Phänomene verwendet wird 

e die Unterstützung der Entwicklung eines gemeinsamen Verständnisses über die kol- 
laborative Arbeit, um eine Grundlage für die Reflexion der individuellen mentalen 
Modelle anzubieten, und damit in Verbindung stehend, 

e eine Unterstützung bei der Identifikation und Auflösung von konfliktionierenden 
Sichtweisen, um Unterschiede in jenen mentalen Modellen, die die Kollaboration 
zwischen Akteuren unmittelbar betreffen, sichtbar zu machen und deren Abstimmung 
zu ermöglichen. 


In den folgenden Abschnitten werden einige Methoden gezeigt, mit denen diese 
Anforderungen umgesetzt wurden. 


5.1.2 _ Compare/WP 


Die oben beschriebenen Anforderungen werden in der Methode „CoMPATE/WP“ exem- 
plarisch umgesetzt. CoMPArE/WP steht für „Collaborative Multi-perspective Articula- 
tion and Elicitation of Work Processes“. Bei der Anwendung von CoMPArE/WP wird 
anhand der Reflexion über einen realen kollaborativen Arbeitsprozess Bewusstsein über 
die Zusammenarbeit in einem konkreten Einzelfall geschaffen. Aufgrund ihrer Ver- 
ankerung an konkreten Arbeitsprozessen eignet sich die Methode auch als Mittel zur 
Organisationsentwicklung. Die Kooperationsform der Methode wird grundsätzlich durch 
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deren Durchführung mit einer Kartenlegetechnik festgelegt. Die teilnehmenden operativ 
Tätigen sind die wesentlichen Akteure und führen die Komponenten eigenverantwortlich 
durch, wobei Artikulations- und Nachfrage-Rollen wechseln können. Die konkrete Aus- 
gestaltung der Kooperation ist in den Komponenten unterschiedlich und deshalb in der 
dort angeführten Prozedur beschrieben. Zur Unterstützung der Durchführung steht ein 
Facilitator bereit, der jedoch nicht inhaltlich interveniert. 

Die Methode soll bei der Artikulation und Abstimmung von mentalen Modellen 
über Arbeit unterstützen und gleichzeitig grundlegende Fähigkeiten zu deren Aus- 
druck in konzeptionellen Modellen vermitteln. Die Kombination diese beiden Teilziele 
hat Auswirkungen auf das Rahmenwerk der Methode. Aus Sicht der Vermittlung von 
Modellierungskompetenz ist es sinnvoll, die notwendigen Fähigkeiten schrittweise mit 
steigender Komplexität einzuführen. Aus Sicht der Artikulationsunterstützung ist ein 
Vorgehen in drei Komponenten argumentierbar. Die Abb. 5.2 gibt eine Übersicht über 
diese drei Komponenten. 

Komponente 1 dient der Findung eines gemeinsamen Verständnisses darüber, wo 
und wie der abzustimmende Arbeitsprozess beginnt und endet, sowie der Findung eines 
gemeinsamen Vokabulars. Komponente 2 dient der Artikulation und Reflexionen des 
jeweiligen individuellen Arbeitsbeitrages. Alle Teilnehmer erstellen hier individuell 
und ohne Interaktion mit anderen ein strukturiertes Modell ihrer Sichtweise auf ihren 
jeweiligen Arbeitsbeitrag. Durch die einheitlich strukturierte Darstellung der individu- 
ellen Beiträge ist in Komponente 3 eine kollaborative Abstimmung derselben möglich. 
Durch diese Abstimmung sollen konfliktionierende Sichtweisen aufgedeckt werden eine 
gemeinsame Sicht auf den gesamten Arbeitsprozess entstehen. 
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Abb. 5.2 Drei Komponenten von CoMPArE/WP 
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In diesen Komponenten sind die Ziele der Kompetenzentwicklung im Modellierungs- 
bereich zu verankern. In Komponente 1 ist die Verbalisierung von mentalen Modellen 
und die darauf aufbauende Konzeptbildung zu vermitteln. In Komponente 2 muss das 
Beschreiben der verbalisierten Inhalte mittels eines vorgegebenen Kategorienschemas 
und einer Notation vermittelt werden. Dabei muss festgelegt werden, welche Elemente 
des Kategorienschemas in der Verantwortlichkeit des artikulierenden Individuums stehen 
und welche als Verhandlungsgegenstände bei der Abstimmung in Komponente 3 validiert 
und gegebenenfalls abstrahiert werden müssen bzw. zur Disposition stehen. 

Konkrete Umsetzung von Komponente 1. Nicht alle Teilnehmer haben not- 
wendigerweise ein gemeinsames Verständnis über die Konzepte, mit denen sie ihre 
Arbeit beschreiben. Um die vorhandenen mentalen Modelle so weit abzustimmen, dass 
ein gemeinsames Vokabular eine Zusammenarbeit ermöglicht, kann kollaboratives 
Concept Mapping eingesetzt werden. Zusätzlich kann ebenfalls nicht davon ausgegangen 
werden, dass ein gemeinsames Verständnis über die Grenzen des abzustimmenden 
Arbeitsprozesses gegeben ist. Auch hier kann Concept Mapping zur Klärung beitragen. 
Neben der inhaltlichen Dimension ermöglichen Concept Maps einen niederschwelligen 
Einstieg in die Welt der konzeptuellen Modellierung, da sie die Bedeutung von Modell- 
elementen nicht vorgeben, sondern diese während der Modellierung durch die beteiligten 
Personen festlegen lassen. Dies erleichtert die Abbildung der individuellen mentalen 
Modelle in die explizite Repräsentation und vermeidet die Notwendigkeit, neben der 
Abstimmung mit den anderen beteiligten Personen auch noch eine Übersetzung auf ein 
Modell mit formal definierte Semantik durchführen zu müssen. 

Im Rahmen dieser Komponente werden die Teilnehmer aufgefordert, alle relevan- 
ten Aspekte der Arbeitsumgebung zu beschreiben, in die der zu reflektierende Arbeits- 
prozess eingebettet ist. Dies erfolgt, indem jeder Aspekt individuell einzeln auf einer 
Karte notiert wird. Bei der Zusammenführung der individuell gesammelten Aspekte 
werden die Karten reihum einzeln auf einer gemeinsamen Arbeitsfläche angeordnet. Die 
Aspekte können zueinander in Beziehung gesetzt werden. Karten mit unterschiedlichen 
Begriffen für den gleichen Aspekt werden überlappend angeordnet. Hierarchische oder 
kausale Beziehungen zwischen Aspekten können durch das explizite Zeichen von Ver- 
bindungen, aber auch durch die räumliche Anordnung der Karten dargestellt werden. 

Das Beispiel in der folgenden Abb. 5.3, das in diesem Abschnitt durchgängig zur 
Erläuterung der Methode herangezogen wird, zeigt eine Concept Map mit relevanten 
Aspekten für die Beantragung eines Urlaubs in einem Unternehmen. Die Aspekte wur- 
den durch räumliche Anordnung zueinander in Beziehung gesetzt. Die überlappenden 
Elemente zeigen Aspekte, die von mehreren Teilnehmern genannt und mit unterschied- 
lichen Begriffen bezeichnet werden. 

Konkrete Umsetzung der Komponenten 2 und 3. Die Komponenten 2 und 3 
fokussieren auf die Artikulation und Abstimmung des wahrgenommenen Ablaufs eines 
Arbeitsprozesses und der darin ablaufenden Interaktion. Die Modellbildung in Kompo- 
nente 2 erfolgt dabei durch alle beteiligten Personen individuell, ohne Interaktion mit 
Anderen. So werden Überlagerungseffekte vermieden und unterschiedliche Sichtweisen 
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Abb. 5.3 Concept Map zum Beantragung von 
Thema Beantragung eines Erholungsurlaub 
Urlaubs 


Urlaubsantrag 


für die nächste Komponente explizit aufgedeckt. Die beteiligten Personen beschreiben 
dabei, welche Arbeitsschritte sie aus ihrer Sicht zur Erreichung des Arbeitsziels bei- 
tragen, mit wem sie interagieren und in welcher Form diese Interaktion erfolgt. 

Die Aushandlung einer gemeinsamen Sichtweise in Komponente 3 und die damit 
einhergehende Erstellung eines gemeinsamen Models erfolgt wiederum mittels einer 
strukturierten Vorgehensweise, die komplexere Modellierungsaufgaben heranführen soll 
und eine einheitlich aufbereitete Modell-Repräsentation gewährleistet. Dabei werden 
die zuvor erstellten Modelle weiterverwendet. Das Strukturierungsschema trennt jene 
Modellaspekte, die in der Verantwortung der jeweiligen Arbeitenden bleiben, von jenen, 
die Gegenstand der Aushandlung sind. 

Zur Darstellung der Arbeitsprozesse wird in diesem Schritt eine strukturierte Dar- 
stellungsform mit vorab spezifizierter Semantik verwendet. Diese ist an den gängigen 
Kategorie-Schemata zur Beschreibung kollaborativer Arbeitsprozesse orientiert (siehe 
Abb. 5.4). Zum Einsatz kommen dabei die Kategorien WER, WAS und AUSTAUSCH 
(M3). WER (blau in der Abbildung) bezieht sich auf die Akteure im Arbeitsprozess, 
WAS (rot in der Abbildung) wird verwendet, um aktive Beiträge im Rahmen des 
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Abb. 5.4 Individuelle Modelle in der vorgestellten Notation 
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Arbeitsprozesses zu beschreiben. AUSTAUSCH (gelb in der Abbildung) wird im Kon- 
text kollaborativer Arbeitsprozesse verwendet, um die Weitergabe oder den Austausch 
von Informationen oder Material zwischen Akteuren im Rahmen der eigenen Tätigkeiten 
zu charakterisieren. Im Sinne der einfacheren Verwendbarkeit werden diese Kategorien 
nicht exakt spezifiziert und lassen bewusst Interpretationsspielraum im konkreten Ein- 
satz — so kann ein WER Element etwa eine konkrete Person, eine Rolle, eine Abteilung 
oder eine gesamte Organisation darstellen. WAS-Elemente verbleiben in der Ver- 
antwortung der einzelnen Teilnehmer, WER und AUSTAUSCH-Elemente sind in Kom- 
ponente 3 Gegenstand der Abstimmung und sollten zu einem gemeinsamen Verständnis 
hin entwickelt werden. 


Individuelle Artikulation In Komponente 2 beschreiben die beteiligten Personen indi- 
viduell mithilfe der Elemente, WAS sie im Arbeitsprozess beitragen, WER mit ihnen 
interagiert, und in welcher Form dieser AUSTAUSCH stattfindet. Zur Unterstützung des 
Artikulationsprozesses wurde ein Strukturierungsschema entwickelt, dass die erstellten 
Modelle in einer einheitlichen Form aufbereitet und deren Zusammenführung im nächs- 
ten Schritt ermöglicht. Das Strukturierungsschema gibt — wie in der obenstehenden 
Abbildung ersichtlich — die räumliche Anordnung der Modellelemente vor. 

Operativ Tätige repräsentieren sich selbst durch ein WER-Element, unter dem die 
wahrgenommenen Beiträge zum Arbeitsprozess als sequenziell angeordnete WAS- 
Elemente platziert werden. Für alle anderen Akteure, mit denen eine Interaktion wahr- 
genommen wird, wir ein weiteres WER-Element platziert, unter dem jeweils die 
Interaktion durch AUSTAUSCH-Elemente näher spezifiziert wird. Deren vertikale Posi- 
tionierungen bestimmen, ob eine eingehende Ressource erwartet wird (Platzierung ober- 
halb des davon abhängigen WAS-Elements), oder ob diese zur Verfügung gestellt wird 
(Platzierung oberhalb des erzeugenden WAS-Elements). 

Die obenstehende Abbildung zeigt drei individuelle Modelle zu dem oben 
beschriebenen Beispiel-Prozess, die entsprechend diesem Strukturierungsschema erstellt 
wurden. Im Beispiel ist ersichtlich, dass es an dieser Stelle zu inhaltlich divergenten 
Repräsentationen vor allem im Bereich der AUSTAUSCH-Elemente kommen kann 
(vgl. „Antrag“ vs. „vollständiger Antrag“ in der obenstehenden Abbildung). Diese 
Divergenzen werden in Komponente 3 explizit sichtbar und sind dann Gegenstand der 
Aushandlung einer gemeinsamen Sichtweise. 


Kollaborative Abstimmung Grundlage der kollaborativen Abstimmung sind die in 
Komponente 2 erstellten individuellen konzeptionellen Modelle. Die folgende Abb. 5.5 
zeigt exemplarisch einen Abstimmungsprozess für zwei der im Beispiel repräsentier- 
ten Akteure. Die gemeinsame Modellbildung erfolgt wiederum auf einer gemeinsamen 
Arbeitsoberfläche (siehe folgende Abbildung Mitte). Jener Teilnehmende, welche auch 
den realen Arbeitsprozess auslöst, beginnt mit der Beschreibung der eigenen Beiträge 
zum Arbeitsprozess und fügt der Oberfläche die entsprechenden Modelle-Elemente 
hinzu (Schritte 1-2 in der folgenden Abbildung). 
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Abb. 5.5 Kollaborative Abstimmung 


Die übrigen Teilnehmenden intervenieren hier nur nachfragend zur Vermeidung von 
Missverständnissen oder zur Offenlegung von Unklarheiten. Eine aktive Beteiligung 
der anderen erfolgt, sobald das erste AUSTAUSCH Element zum Einsatz kommt 
(Schritte 3-4). Sofern eine grundlegend gemeinsame Sichtweise auf den Arbeits- 
prozess existiert, sollte an dieser Stelle einer der Teilnehmenden ein entsprechend 
zuzuordnendes AUSTAUSCH-Element einbringen können (Schritte 5-7). 

Ist dies der Fall, so wird der Beschreibungsprozess durch diese Person fortgesetzt (ab 
Schritt 8). Bei einer grundsätzlichen Passung, die sich jedoch in der Bezeichnung des 
Elementes — etwa durch unterschiedliche Abstraktionsebenen - unterscheidet, muss diese 
mehrfache Bezeichnung aufgelöst werden oder die semantische Äquivalenz der beiden 
Elemente durch überlappendes Anordnen dargestellt werden (z. B. Schritt 7). Falls kein 
zuzuordnendes Element vorhanden ist, wird eine grundsätzlich divergierende Reprä- 
sentation sichtbar. Diese kann auf mangelndes Relevanzbewusstsein eines Austausches 
zurückzuführen sein. Dies bedeutet, dass dem angesprochenen Teilnehmenden die 
Interaktion zwar bewusst war, aber im Kontext des Arbeitsprozesses als nicht relevant 
erschien. Falls eine wahrgenommene Interaktionserfordernis eines Teilnehmenden nicht 
erwidert wird, muss es jedoch zu tiefer gehenden Aushandlungsprozessen kommen. 

Der initiale Abstimmungsprozess endet, sobald alle Teilnehmenden ihre indivi- 
duellen Modelle erläutert und zum gemeinsamen Modell hinzugefügt haben. Dieser 
Externalisierungs-Phase folgt eine kollaborative Reflexionsphase, im Rahmen derer der 
Arbeitsprozess anhand des gemeinsamen Modells durchgegangen und hinsichtlich seiner 
Passung auf die individuellen Sichtweisen der Beteiligten diskutiert wird. Etwaige not- 
wendige Modifikationen werden an dieser Stelle nach einer Konsensbildung der jeweils 
Betroffenen durchgeführt. 
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Das Ergebnis der Anwendung der Methode stellt nun eine konsensuale Repräsentation 
des kollaborativen Arbeitsprozesses dar. Aufgrund der eingeschränkten Ausdrucksstärke 
der eingesetzten Modellierungssprache ist an dieser Stelle die Abbildung von — 
ansonsten in Prozessbeschreibungen üblichen — Arbeitsvarianten oder Entscheidungen 
nicht möglich. Die Entscheidung für eine semantisch auf wenige Elemente beschränkte 
Modellierungssprache fiel aufgrund didaktischer Kriterien, da empirische Belege zeigen, 
dass unerfahrene Modellierende ihre Sichtweisen auf einen Arbeitsprozess initial einfacher 
narrativ anhand eines konkreten Falles beschreiben können. 

Entscheidungen hinsichtlich der konkreten Umsetzung des Arbeitsprozesses sind 
bei der fallbasierten Beschreibung bereits getroffen. Damit ist eine explizite Reprä- 
sentation derselben im Rahmen der Modellierung nicht notwendig. Eine vollständige 
Beschreibung des Arbeitsprozesses bedingt somit eine mehrfache Durchführung der 
Methode oder deren Erweiterung um weitere Verfeinerungsschritte, die aber an dieser 
Stelle nicht näher betrachtet werden sollen. 

Im Sinne der Bildung von Modellierungskompetenz liegt der Fokus in Komponente 
l] auf der Hinführung zur für die Modellbildung notwendige Abstraktion und Kon- 
zeptualisierung von Wahrnehmungen der realen Welt. In Komponente 2 erfolgt die durch 
Strukturhilfen angeleitete Darstellung und Reflexion der eigenen Arbeitswahrnehmung 
in konzeptionellen Modellen und deren Beschreibung mittels vorgegebener Struktur- 
elemente. Komponente 3 fokussiert in der Folge auf Modell-Verständnis (der anderen 
individuellen Modelle), -Interpretation (hinsichtlich deren Auswirkungen auf das eigene 
Modell) und -Aushandlung (der gemeinsam vertretbaren Sicht) von Modellinhalten, 
wodurch letztendlich die Kompetenz zur selbstermächtigenden Beeinflussung von 
Arbeitsprozessen vermittelt wird. 

Zur Auseinandersetzung mit der Wirkung einer konkreten Anwendung der Methode 
muss der Begriff der „Selbstermächtigung‘“ gefasst werden. „Selbstermächtigung‘“ kann 
nach Liebert (2015) folgendermaßen verstanden werden: „[Der] Begriff der Selbst- 
ermächtigung [...] fordert [...] dazu auf, sein Schicksal in die eigene Hand zu nehmen, 
seine individuellen Ansprüche nicht nur zu formulieren, sondern auch — aktiv — durch 
„Selbsttätigkeit‘ umzusetzen —, auch wenn dies bedeutet, gegen die eingespielten Regeln 
und etablierten Strukturen der institutionellen Ordnungen zu verstoßen.“ 

Die Methode soll nun zur „Selbstermächtigung“ im Sinne dieser Definition füh- 
ren. Der Anspruch, Arbeitende in die Lage zu versetzen, „individuelle Ansprüche [...] 
zu formulieren“, ist das grundlegende Gestaltungsziel der vorgeschlagenen Methode. 
Die Zielsetzung, dazu zu befähigen, „diese [Ansprüche] auch — aktiv — durch Selbst- 
tätigkeit umzusetzen“ wird im Kontext durch Arbeitsbeeinflussungssystem gesteuerter 
Arbeitsprozesse insofern entsprochen, als dass operativ Tätige dazu befähigt werden, die 
konzeptionelle Modellierung von Arbeitsprozessen als jene „Sprache“, die zu Konfigu- 
ration existierender Arbeitsbeeinflussungssystemen verwendet wird, nicht nur zu ver- 
stehen, sondern auch selbst zum Einsatz zu bringen. Dies soll dazu führen, dass diese 
sozio-technischen Systeme — wie zu Beginn argumentiert — als Arbeitsunterstützungs- 
systeme einsetzen zu können, die den Arbeitsprozess und die zur Zielerreichung 
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notwendige Kollaboration für die handelnden Individuen erleichtern können. Die 
Befähigung, diese „Umwidmung“ vorantreiben zu können, bildet die Grundlage dafür 
„die institutionelle Ordnung [...] infrage zu stellen und in letzter Konsequenz durch neue 
Formen der ‚freien‘ Selbstorganisation zu überwinden.“ 

Die Akzeptanz existierender organisationaler und technischer Rahmenbedingungen 
und der Unabdingbarkeit ihres weiteren Einsatzes, die — wie in der Einleitung dar- 
gestellt — einen Ausgangspunkt dieser Methode bildet, stellt gleichzeitig die größte 
Herausforderung bei der Ermöglichung von Selbstermächtigung im organisationalen 
Kontext dar. Die Verwendung dieser Unterstützungssysteme ermöglicht nicht nur eine 
Fremdsteuerung, sondern auch eine Selbstdisziplinierung im Sinne der Erreichung vor- 
gegebener Ziele, die mit der Verfügbarkeit technischer Unterstützung bei Planung und 
(Selbst- wie Fremd-)Kontrolle sogar erleichtert wird. 

Die Verwendung der Werkzeuge des klassischen Geschäftsprozessmanagements zur 
Bildung von Reflexions- und Gestaltungskompetenz von Arbeitsprozessen birgt dar- 
über hinaus für operativ Tätige das Potenzial, die entwickelten Kompetenzen auch zur 
Optimierung von Arbeitsprozessen aus betriebswirtschaftlicher Perspektive einzusetzen 
bzw. dazu angehalten zu werden. Während dies nicht per-se dem Konzept der Selbst- 
ermächtigung entgegensteht, kann gleichzeitig auch nicht von einer Kohärenz der Inter- 
essen beider Gestaltungsperspektiven ausgegangen werden. Im Sinne einer nachhaltigen 
Verankerung der selbstermächtigten Gestaltung von Arbeitsprozessen in Organisatio- 
nen muss diese Kohärenz aber angestrebt und auch explizit sichtbar gemacht werden. 
Dies stellt eine große Herausforderung im Kontext des Einsatzes von Geschäftsprozess- 
modellierung zur Organisationsentwicklung dar und muss als solche auch vor und wäh- 
rend des Einsatzes der vorgestellten oder ähnlicher Methoden der akteurszentrierten 
Geschäftsprozesserhebung und -modellierung berücksichtigt werden. 


5.1.3 Bewusstmachen von prozessrelevantem 
Veränderungspotenzial 


In der Folge wird zunächst die Value Network Analysis vorgestellt, wie sie im Wissens- 
management zur Bearbeitung von Leistungsbeziehungen zwischen vernetzten Akteuren 
eingeführt wurde, ehe ihr Potenzial für die Prozessanalyse- und -modellierung detailliert 
wird. 


5.1.3.1 Value Network Analysis 

Betrachten wir, wie eingangs erwähnt, die Wertschöpfung von Organisationen, und damit 
die Ebene der leistungsbezogenen Austauschbeziehungen zwischen Akteuren, so kön- 
nen im Rahmen von Arbeitsvorgängen tangible von intangible Austauschbeziehungen im 
Netzwerk von Akteuren unterscheiden werden. Tangibler Austausch wird durch Energie- 
und Materialflüsse bestimmt. Intangibler Austausch, wie Wissen, verweist auf kogni- 
tive Prozesse und handlungsleitende Information. Werden nun TeilnehmerInnen und 
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Austauschbeziehungen beschrieben, kann so die Struktur einer Organisation oder eines 
Netzwerks erfasst werden. 

Austauschbeziehungen stellen die molekulare Ebene ökonomischer Aktivitäten dar. 
Somit besteht Wertschöpfung nicht nur aus tangiblen Transaktionen, sondern auch aus 
darüber hinausreichenden, intangiblen Transaktionen. Diese beziehen sich vor allem auf 
den kognitiven Austausch, da nachhaltiger Erfolg einer Organisation auf Informations- 
austausch, Wissensteilung und offenen kognitiven Pfaden, die situationsgerechte Ent- 
scheidungsfindung (und damit erfolgreiches Bestehen einer Organisation) ermöglichen, 
beruht. Wissen und intangible Elemente verhalten sich allerdings anders als physische 
Ressourcen im Geschäftsleben, sodass sie nicht als tangibel betrachtet werden können. 
Sie konstituieren aufgrund ihrer Nähe zu lebenden Systemen eine eigene Kategorie 
von Austausch, und unterscheiden sich vom tangiblen Austausch mit Bezug zu Gütern, 
Dienstleistungen und Erträgen. 


Tangibler Austausch ist nach Allee [2] definiert über Transaktionen, die Güter, Dienst- 
leistungen oder Erträge beinhalten, z. B. physische Güter, Verträge, Rechnungen, Liefer- 
und Empfangsbestätigungen, Anfragen, Aufforderungen, Bietereinladungen, Zahlungen. 
Wesentlich dabei ist, dass wissensintensive Produkte und Dienstleistungen, welche 
Erträge bewirken und für die Zahlungen als ein Teil einer Dienstleistung oder eines Pro- 
dukts geleistet werden bzw. aufgrund einer vertraglichen Verpflichtung zu leisten sind, 
auch als tangible Transaktionen betrachtet werden. 


Intangibler Austausch von Wissen und Leistung unterstützt Kernprozesse und 
damit die klassische Wertschöpfungskette, unterliegt aber keinerlei vertraglicher Ver- 
pflichtung. Intangibles sind ‚Extras‘ bzw. (kleine) Aufmerksamkeiten, die Personen 
einander zukommen lassen, um Beziehungen aufzubauen und Abläufe ohne Störungen 
bzw. angenehm ablaufen zu lassen. Intangible Transaktionen inkludieren den Austausch 
strategischer Information, Planungswissen, fachlich-operatives Wissen, gemeinsame 
Planungsaktivitäten, kollaborative Gestaltung, und policy-Entwicklung. Intangible Trans- 
aktionen sind folglich nicht vertraglich vereinbarte Leistungen zum Nutzen oder zur 
Unterstützung von Organisationen bzw. ihrer Mitglieder. Sie können von einer Person 
oder Gruppe zu anderen ausgeweitet werden, indem beispielsweise ein Experte für eine 
bestimmte Zeit von einer Organisationseinheit zur Mitarbeit aufgefordert wird, für den 
dies Prestige bedeutet. Anerkennung hilft oft in der Beziehungsarbeit, sodass intangible 
benefits echte Motivationsfaktoren für rege Beteiligung und aktive Teilnahme an 
Gruppenaktivitäten darstellen. 

Intangibles stellen das Kernstück allen menschlichen Handelns dar, und bestimmen 
somit auch sozio-ökonomisches Handeln. Intangible Transaktionen werden bewusst 
gesetzt. Sie können herbeigeführt und erkannt werden. Soll verstanden werden, wie 
intangibles Wert generieren, ist zunächst zu verstehen, wie sie als negoziables in öko- 
nomischen Austauschbeziehungen sichtbar werden und wirken. Sie sind oft nicht unmittel- 
bar sichtbar, vielmehr ‚verpackt‘ in Dienstleistungen oder Produkten. Ein typisches 
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Beispiel ist, Verständnis für eine Kundensituation aufzubauen (intangibel), bevor eine Leis- 
tung (tangibel) angeboten wird. Für eine Praxisgemeinschaft ist unmittelbar der störungs- 
freie Gang von Prozessen von Bedeutung. So sind jene Transaktionen wesentlich, welche 
(auch) mittels intangibles gewährleisten, dass ein gemeinsamer Zweck des Handelns 
sichergestellt ist. Es gilt dies nun methodisch zu berücksichtigen. 

In einem Value Network werden mittels komplexer dynamischer Austauschvorgängen 
zwischen zwei oder mehreren Individuen, Gruppen oder Organisationen tangible und 
intangible Werte generiert, die den Gegenstand der reflektierenden Gestaltung darstellen. 


5.1.3.2 Holomapping 

Die auf Vernetzung beruhende Sichtweise zur organisationalen Wertgenerierung 
bringt eine neue Form der Organisationsmodellierung mit sich, jeder Austausch einen 
Mechanismus bzw. ein Medium als enabler für Transaktionen erfordert. Diese können 
Arbeitsmittel wie e-mail oder face-to-face-Interaktionen in Communities of Practice 
sein. Typische intangibles betreffen, wie oben bereits angesprochen, Wissen zur 
Informationsgewinnung von Kunden und Feedback zu (Produkt-)Entwicklungen. 

Die Darstellung tangibler und intangibler Austauschprozesse in einem Diagramm mit 
Flusselementen erlaubt die Dynamik von lebenden Systemen abzubilden. Zunächst wer- 
den die Teilnehmer oder Rollen (auch Gruppen, Teams oder Organisationseinheiten, aber 
keine technischen Hilfsmittel) dokumentiert — sie bilden die Knoten des Netzwerks und 
werden oval visualisiert. Die Teilnehmer senden oder ergänzen sogenannte deliverables 
an andere Teilnehmer. Pfeile zeigen die Richtung an, welche die deliverables im Verlauf 
einer bestimmten Transaktion nehmen, bezeichnet mit dem jeweiligen deliverable. 

Transaktionen oder Aktivitäten werden als gerichtete Kanten (Pfeile) dargestellt, 
wobei der Ursprung bei einem Teilnehmer und das Ende bei einem anderen Teilnehmer 
zu sein hat. Der Pfeil zeigt Bewegung an und gibt die Richtung vor, in die etwas zwi- 
schen zwei Teilnehmern geschieht. Im Gegensatz zu Teilnehmern, welche zeitstabil sind, 
sind Transaktionen zeitlich begrenzt und flüchtig. Sie besitzen einen Startpunkt, eine 
Dauer und einen Abschluss. 

Deliverables hingegen sind echte ‚Dinge‘, die sich von einem Teilnehmer zu einem 
anderen bewegen. Ein deliverable kann materiell (tangible) sein, wie ein Dokument 
oder ein Tisch, oder ideell (nicht am Materie gebunden), wie eine Nachricht oder eine 
Anforderung, die nur verbal überbracht wird. Deliverables können auch intangibel 
sein, wie beispielsweise Wissen über einen bestimmten Sachverhalt (kognitiv) oder 
ein Gefallen (sozial/emotional). Pfeile sind immer nur in eine Richtung zulässig — sie 
umfassen eine einzige Transaktion. Beidseitige gerichtete Pfeile sind bedeutungslos, 
vielmehr verunmöglichen sie eine Analyse der Abläufe und Austauschbeziehungen. 

Ein Austausch tritt dann auf, sobald eine Transaktion in einem deliverable resultiert, 
das zurückkommt. Er muss in der praktischen Handlungswelt in Organisationen nicht 
zwangsläufig gegeben sein. Tritt er allerdings auf, kann sich ein Value Network etablie- 
ren, mit Transaktionen als molekulare Elemente der Wertegenerierung. 
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Wesentlich ist im Rahmen von Veränderungsprozessen die Ermächtigung der 
Beteiligten, und somit die Erstellung der Kommunikationslandkarte mit tangiblen und 
intangiblen Beziehungen (Holomap) durch die betroffenen Rollenträger, ebenso wie die 
Bearbeitung der erhobenen Daten durch diese im Rahmen der 3 Value Network-Analysen. 

Im Rahmen der Wissensgenerierung bzw. Wissenserhebung zu Beginn der 
Bearbeitung der Netzwerkstruktur überlegt jeder einzelne Teilnehmer seine Rolle, wel- 
che er dann den anderen Teilnehmern mitteilt. So werden Beziehungen und Wechsel- 
wirkungen zwischen den einzelnen Rollen, die oft nicht bekannt sind, explizit und klarer. 
Die Rollen werden als Knoten symbolisiert, der Austausch von materiellen oder ideellen 
Werten wird in Form von Linien dargestellt, die die Rollen miteinander verbinden. Die 
Modellierung bildet die Basis für die anschließenden Analysen zur Wissensauswertung 
und -verarbeitung. 


5.1.3.3 Exchange Analysis 

Ausgangsbasis für die Exchange Analyse stellt die Holomap dar. Wie bereits erwähnt, 
beziehen sich Tangibles (materielle Wertflüsse) im Netzwerk dabei auf den materiellen 
Austausch zwischen Personen (typischerweise Waren, Dienstleistungen und Umsatz- 
erlöse). Sie repräsentieren Transaktionen, die auf Verträgen basieren. Intangibles 
(nicht-materielle, ideelle Wertflüsse) basieren im Unterschied zu tangibles auf Wissen 
oder einem bestimmten Zusatznutzen. Sie sind nicht vertraglich fixiert oder kosten- 
pflichtig. Oft erhobene intangibles sind strategische Informationen, Prozess- oder 
Planungswissen sowie bestehende emotionale Komponenten wie gegenseitiges Ver- 
trauen, gemeinsames Interesse, Wissensbedarf, Sicherheit etc. — siehe auch Abb. 5.6 mit 
Holomap zu Customer Service. 

Die Exchange-Analyse untersucht ein Value Network auf seine Schlüssigkeit, Robust- 
heit und Nachhaltigkeit. Sie gibt Einblick über die aktuelle Struktur und Dynamik des 
Netzwerks. Folgende Fragestellungen sollen die Exchange-Analyse unterstützen: Wie 
fließen die Werte durch die Organisation? Zeichnet sich eine bestimmte Logik ab? Ist 
das Verhältnis des Austauschs von materiellen und ideellen Werten ausgeglichen oder 


Abb. 5.6 Auszug einer 
Holomap zu Customer Service 
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überwiegt eine bestimmte Art des Austausches? Zeigt das Muster im Value Network 
reziproke Wertflüsse auf oder gibt es beispielsweise Teilnehmer, die mehr Wertflüsse 
erhalten als bereitstellen? Gibt es im Netzwerk ineffektive Verbindungen, die Wertflüsse 
nicht weitergeben? 

Durch diese Fragen soll überprüft werden, ob das Netzwerk seinen Zweck erfüllt, 
fehlende Endknoten oder Verknüpfungen zu erkennen sind, und wie die Struktur 
des Netzwerkes optimiert werden kann. Sie gewährleisten einen generellen Über- 
blick über Wertschöpfung und Wertverlust. Die Exchange Analyse soll als Anregung 
zum Dialog dienen, komplexe Systeme zu verstehen und Systemdenken [3] fördern. 
Die Exchange-Analyse zu Customer Service, etwa in der Annahme, es handelt sich 
um die Organisation facebook, zeigt mehrere Befunde: Customer Service ist aus Sicht 
der Produktentwicklung tangible Senke — es empfängt nur Feature List. Der Verkauf 
bekommt zwar Lifestyle-info, aber keine vertrauensbezogene Information. Die Über- 
setzung von Unsicherheit lastet auf Customer Service zu Verkauf und zu Produkt- 
Entwicklung. Diese erste Auswertung kann ein Indiz für die in Abbildung gezeigte 
Informationsgebarung sein, wo Features zwar eine bestimmte Form der Rückkoppelung 
ermöglichen, die aber seitens der NutzerInnen gegebenenfalls mit Anfragen, die 
Unsicherheit widerspiegeln, quittiert wird. 


5.1.3.4 Impact Analysis 

Die Impact-Analyse (Wirkanalyse) untersucht die Auswirkung jedes einzelnen Werte- 
Input auf die Teilnehmer und legt so ihren Fokus auf die Empfangenden von Werte- 
Inputs. Diese Analyse zeigt also auf, welcher Input welche Reaktionen und Aktivitäten 
auslöst und wie sich dieser auf die materiellen und ideellen Vermögensgegenstände 
der betroffenen Empfänger auswirkt. Anschließend werden Kosten und Nutzen von 
Werte-inputs mit niedrig, mittel oder hoch bewertet. 

Um einen besseren Überblick über diese Fragen zu erlangen, werden für jeden einzel- 
nen Empfänger von Werte-inputs die Antworten in eine Tabelle eingetragen und die 
Ist-Situation analysiert. Die Tabelle zeigt die Impact-Analyse auf Basis der gewonnenen 
Erkenntnisse aus der Exchange-Analyse eines Customer Service-Mitarbeiters. In der 
Tabelle wird abgebildet, von wem Input für welche Aktivitäten kommt und welche 
Auswirkungen in Form materieller oder ideeller Werteflüsse wahrgenommen werden. 
Wesentlich für die Abschätzung von Veränderungspotenzial sind die Spalteneinträge zu 
den allgemeinen Kosten und Risiken sowie zum Nutzen von dem angesprochenen Input. 

Die Daten der initialen Auswertung (Exchange-Analyse) stellen also eine Basis 
für die beiden weiteren Analysen dar, wobei aus der Sicht von erhaltenem Input 
(Impact-Analyse) und übermitteltem Output (Value Creation-Analyse) wertebasiert 
detaillierte Auswertungen von Transaktionen erfolgen und so Erkenntnisse für Ver- 
änderungsprozesse mit sich bringen. 

So wird beispielsweise, wie in der Tabelle ersichtlich, ausgeführt, wann Features 
eine gelungene Form der Informationsrückkoppelung ermöglichen, um etwa Anfragen 
zu vermeiden, die Unsicherheit seitens der Nutzer widerspiegeln. Dies, selbst wenn der 
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derzeitige Nutzen der Darstellung von Features seitens des Customer Service aufgrund 
mangelnder Verständlichkeit als gering eingeschätzt wird. 

Aus den Einträgen der Tabelle zur Feature List wird ebenfalls der für die Wert- 
schöpfung relevante Bezugspunkt ersichtlich, und zwar die Qualität der Auskunfts- 
leistung an Kunden durch Customer Service-Mitarbeiter. 

Aufbauend auf der Ist-Analyse können darauf folgend strategische Perspektiven 
abgeleitet werden und die Tabelle noch einmal im Vergleich dazu hinsichtlich ihrer 
geplanten, strategischen Aktivitäten (Soll-Analyse) ausgefüllt werden. Im gegenständ- 
lichen Fall kommt beispielsweise einer kundenorientierten Auskunftsleistung erhöhte 
Bedeutung zu. 


5.1.3.5 Value Creation Analyse 

Die Value Creation-Analyse analysiert wie Werte bestmöglich erschaffen, erhöht und 
eingesetzt werden können. Wie die Impact-Analyse betrachtet die Value Creation- 
Analyse auch die einzelne Rolle im Bezug zum gesamten System. Der Unterschied 
zur Impact-Analyse besteht darin, dass im Gegensatz zum Input diesmal der Sender 
oder Produzent von Output in seiner Rolle und mit seinen diesbezüglichen Aktivitäten 
betrachtet wird (siehe Abb. 5.7). 

Jeder einzelne Sender von Werte-outputs wird analysiert, wie im Ist-Zustand Mehr- 
wert und Wertezuwachs zum bestehenden Werte-output realisiert wird. Auch hierzu wird 
eine Kosten/Nutzenabschätzung vorgenommen. 

Bei der in der Tabelle gezeigten Value Creation-Analyse (oder Wertschöpfungs- 
analyse) wurde anhand erzielter Arbeitsergebnisse analysiert, wie Werte bestmöglich 
erschaffen, erhöht und eingesetzt werden können. Die Tabelle zeigt die Analyse auf 
Basis der Daten der Exchange-Analyse eines Kundenberaters. 


Auswirkungen auf die Kosten Auswirkungen auf die Wie hoch sind die | Wie hoch ist der 
und materiellen immateriellen allgemeinen allgemeine Nutzen 
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Kosten / Risiken und Nutzen N=niedrig, M= mittel, H= hoch] 


Abb. 5.7 Teil einer Impact Analyse zu Customer Service 
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An Leistungsindikatoren können aus den Analysen die Anforderungen, die an den 
Verkauf sowie die Produktentwicklung gestellt werden, gefiltert werden. Die daraus ent- 
wickelte Strategie kann mit der Aussage ‚Verfügbarkeit bzw. Transparenz von Informa- 
tion‘ umrissen werden. So könnte als Veränderungsmaßnahme beschlossen werden, das 
identifizierte Wertschöpfungspotenzial im Value Network durch Erweiterung der tangiblen 
Informationsflüsse zwischen allen funktionalen Einheiten zu steigern. 

Nach der Darstellung der Ist-Situation ermöglicht auch die Value Creation-Analyse 
strategische Perspektiven abzuleiten. Hier sollte sich die Frage gestellt werden, wel- 
che Möglichkeiten in Zukunft noch genützt werden sollen, um Wertoptimierung beim 
Werteoutput zu generieren. Hinsichtlich der konkreten Frage ‚Was soll getan werden, um 
eine Wertsteigerung, -ausweitung oder -optimierung von Output zu erzielen?‘ wird die 
Tab. 5.1 zur Analyse der Soll-Situation vergleichend ausgefüllt. 

Wesentlich zur Entscheidungsunterstützung sind die Einträge in die Spalten ‚Kosten/ 
Risiken‘ und ‚Nutzen‘. Hier kann sich die Einschätzung vor allem bei Kosten und Risi- 
ken bei der Soll-Situation relativieren, wenn beispielsweise Inhalte in Schulungen auf- 
genommen werden sollte, da es Know-How zur Erstellung entsprechender Unterlagen 
sowie der Bereitstellung effektiver Vermittlungsformate im Netzwerk gibt (etwa im 
Kontext ‚Report‘- dritter Tabelleneintrag in der Tabelle). Eine Soll-Aufstellung berück- 
sichtigt zumeist Wissen über die Machbarkeit bzw. Verfügbarkeit von Ressourcen und 
damit verbundene Aufwände zur Umsetzung von Maßnahmen, und zwar ohne eine dies- 
bezügliche Entscheidung vorwegzunehmen (siehe Auswertung). 


5.1.3.6 Auswertung 


Für die Auswertung werden in Tabellenform (Impact-Analyse, Exchange-Analyse, Value 
Creation-Analyse) tangibles und intangibles nach ihrer Bedeutung für die jeweilige(n) 


Tab.5.1 Teil der fallbezogenen (Customer Service) Value Creation-Analyse 


Output des Senders | Output Adressat Wertsteigerung, Kosten/Risiken | Nutzen 
T Mehrwert der Aktivität 
Feedback- Produkt-Entwicklung | Kundenorientierter H/H H 
Verständlichkeit Zugang 
Berücksichtigung der 
Machbarkeit 
Auskunft Kunde Bedürfnisgerechter H/H H 
Umgang 


Wäre auch für 
potenzielle Kunden 
interessant 


Report Verkauf Gewinnung von H/H H 
Kundendaten 

wäre auch für Schulung 
interessant 


Bei Kosten/Risiken und Nutzen: N = niedrig M = mittel H=hoch 
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Rolle(n) bewertet. Anhand dieser Bewertungen werden Auswirkungen auf Beziehungen 
sichtbar und es können gezielt Maßnahmen gesetzt werden. 

Bislang wurde mit der Durchführung der Exchange-Analyse Einblick über die 
aktuelle Struktur und Dynamik des Netzwerks geschaffen. Die Durchführung der 
Impact-Analyse erlaubt allen Teilnehmern ihre eigenen Rollen im Netzwerk kontext- 
sensitiv zu erschließen. Die Impact-Analyse ermöglicht einen Überblick, welche 
Auswirkungen jede einzelne Wertetransaktion auf die Teilnehmer hat. Die Value Creation- 
Analyse erlaubt hingehen zu befinden, wie Werte bestmöglich geschaffen, erhöht und 
eingesetzt werden können, und gegebenenfalls auf andere Rollen wirken bzw. diese 
miteinbeziehen sollten. Anhand der abgeleiteten Leistungsindikatoren kann nun eine 
Strategie entwickelt werden, um das identifizierte Wertschöpfungspotenzial im Value 
Network zu steigern. 

Typische Ergebnisse einer Auswertung zur Steigerung der Wertschöpfung umfassen 
die Berücksichtigung fehlender Austauschbeziehungen, also beispielsweise auf den 
gegenständlichen Fall bezogen: 


e Konkrete Anfragen an Kunden, um deren Anliegen (insbesondere jene, welche zur 
Verunsicherung von Kunden führen) aus Sicht der Produktentwicklung und des Ver- 
kaufs besser verstehen zu lernen — Customer Service nimmt hier eine Mittlerrolle ein, 
wodurch auch der tangible Report aufgewertet werden und das Feedback konkrete 
Hinweise zur Verbesserung bzw. Schaffung von Features beinhalten kann. 

e Feedback von Kunden, das sowohl den zukünftigen Umgang als auch den bisherigen 
Umgang mit Features, also im Besonderen die Produktentwicklung betrifft. Sobald 
die Verständlichkeit der Darstellung explizit adressiert wird, kann ein diesbezüglicher 
Informations(rück)fluss zur Produktentwicklung (und auch zum Verkauf) sichergestellt 
werden — eine weitere Maßnahme, die den kundengerechten Zugang zum Produkt 
erleichtert. 


Beide Maßnahmen zeigen die Notwendigkeit vernetzter Darstellung von Austausch- 
beziehungen. Es ist nicht unbedingt die Unmittelbarkeit von Austauschbeziehungen, 
sondern vielmehr die Verkettung von Austauschbeziehungen, die Mehrwert bewirken 
kann. Würde beispielsweise die Produktentwicklung (z. B. Softwaredesigner) direkt mit 
Kunden beginnen zu kommunizieren, wäre zunächst eine bestimmte Gesprächsbasis her- 
zustellen. Derartige Maßnahmen könnten für den zu erreichenden strategischen Zweck 
sogar kontraproduktiv sein und die bestehende Verunsicherung aufseiten der Kunden 
noch erhöhen, und damit dem angestrebten Ziel zuwider laufen. 

Die Ergänzungen des Netzwerks (siehe Abb. 5.8) erlauben somit eine kontextsensitive 
Systembetrachtung der Wertschöpfung durch materielle und ideelle Leistungen, die zwi- 
schen den beteiligten Akteuren fließen sollten. Die vervollständigte Value Network Map, 
wie in der Abbildung gezeigt, bildet die Grundlage für die weitere Entwicklungsplanung. 
Sie zeigt die Anfrage an Kunden sowie das Feedback zur Verständlichkeit erstmals als tan- 
gible deliverable, wodurch sich die Informiertheit der Beteiligten durch die Transparenz 
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und Verfügbarkeit von Information erhöhen soll. Langfristig anzustreben ist als intangibler 
Austausch zwischen Kunden und Customer Service ein durch wechselseitige Sicherheit 
geprägter Umgang, der sich mit Loyalität der Kunden zur Organisation ausdrücken lässt. 
Erst durch den offenen Austausch an Information wird nachhaltiges Customer Knowledge 
Management möglich. 

Value Networks betrachten Systeme in ihrer Gesamtheit und berücksichtigen deren 
Komplexität. Sie ermöglichen die ganzheitliche Identifikation von materiellen als auch 
ideellen Werten. Letztere bestimmen jedenfalls indirekt die Qualität materieller Aus- 
tauschbeziehungen und sind folglich bei der Entwicklung sozio-technischer Systeme mit 
zu berücksichtigen. Der durch Value Networks einnehmbare Fokus auf die beteiligten 
Individuen fördert die Sinnstiftung und Motivation derselben zur Beteiligung an Refle- 
xion und aktiven Mitgestaltung. Die vorgestellten Erhebungen und Analysen erlauben 
die Explikation einzelner Rollen und deren direkt oder indirekt wahrgenommener Bei- 
trag zur Wertschöpfung eines organisationalen Systems durch Akteure. Dies erleichtert 
die Rollenklärung sowie das Verständnis von Zusammenhängen, da diese mittels Wert- 
austauschbeziehungen grafisch in Holomaps visualisiert, und somit rollenspezifisch 
rückgekoppelt werden. Sie stellen somit einen viablen Ausgangspunkt partizipativer 
Gestaltung sozio-technischer Systeme dar. 


5.1.3.7 Potenziale für Prozessanalyse und -modellierung 
Für die Gestaltung von Prozessen und deren Modellierung lassen sich aus der Value Network 
Analysis mehrfach Potenziale schöpfen: 


e Die Value Network Analysis erlaubt die Repräsentation einer Situation, wie sie 
von Handlungsträgern wahrgenommen wird. Die Darstellung der Situation erfolgt 
anhand von Rollen, die durch Knoten eines Netzes von Akteuren repräsentiert wer- 
den. Da jeder Rollenträger diese Analyse durchführen kann, können individuell 
wahrgenommene Interaktionsmuster mit der Wahrnehmung anderer Rollenträger 
gegenübergestellt und abgeglichen werden. Somit erlaubt die Value Network Analysis 
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die strukturierte Feststellung von unterschiedlich wahrgenommenen Interaktions- 
mustern zwischen Handlungsträgern aus deren Sicht, wobei die unterschiedlichen 
Interaktionsmuster auch kumuliert dargestellt werden können. 

e Die Erfassung und Darstellung der Ist-Situation stellt einen Referenzpunkt dar, von 
dem aus Veränderungspotenziale erschlossen werden können. Damit können für 
alle Beteiligten nachvollziehbar Änderungen von Interaktionen auf der Basis einer 
gemeinsamen Ausgangslage diskutiert werden. 

e Die Value Network Analysis erlaubt die Bestimmung von Rollen, welche nicht zwin- 
gend funktional in einer Organisation, etwa im Organigramm, zu finden ist. Die 
Rollenbestimmung orientiert sich an den Kommunikations- und Interaktionsmustern, 
welche im Rahmen der Aufgabenerfüllung und dem wahrgenommenen Organisations- 
geschehen als relevant erachtet werden. Somit rücken die fachliche und die Inter- 
aktionsebene in den Vordergrund. 

e Im Rahmen der Erarbeitung von Veränderungsvorschlägen, werden anstelle von 
Forderungen einzelner Rollenträger Vorschläge an andere im Sinne individueller 
Angebote an das Kollektiv gemacht. Eine derartige Vorgangsweise stellt den Adres- 
saten frei, dieses Potenzial zu nutzen. Sämtliche Angebote werden im Kontext ihrer 
Herkunft dargestellt und bezüglich ihrer organisationalen Wirksamkeit von den 
jeweilig vorschlagenden Handlungsträgern bewertet und können darauf aufbauend im 
Kollektiv abgestimmt werden. 

e Interaktionsbeziehungen werden differenziert nach vertraglich verpflichtenden 
Leistungen (tangibles) und nicht nur aus der jeweiligen Rolle nach vertragsmäßig 
geregelten Leistungen (intangibles). Damit wird bereits evident, in welcher Form 
die Bewältigung von Aufgaben erfolgt, ob eher nach formellen Grundsätzen oder 
Interaktionen, welche eine erfolgreiche Prozesserfüllung begünstigen, oder nach 
informellen Grundsätzen. Gleiches gilt für Änderungsvorschläge, die ebenfalls 
in formelle Strukturen (als Teil von funktionalen Rollenbeschreibungen) oder auf 
informeller Ebene angesiedelt (als freiwilliger Beitrag) sein können. 

e Die Veränderung einer Ist-Situation in einen Soll-Zustand kann auf mehreren Wegen 
erfolgen: i) eine informelle (intangible) Interaktion wird formeller Teil einer Rolle 
(tangible); ii) eine formelle (tangible) Interaktion wird weggelassen oder informeller 
Teil einer Rolle (intangible); iii) eine tangible bzw. intangible Beziehung wird neu 
eingeführt und ergänzt bestehende Interaktionsmuster. 

e Interaktionsbeziehungen sind direkt überführbar in konkrete Prozessschritte, da sie 
zeitlich aneinandergereiht die Erfüllung von Aufgaben durch die Rollenträger reprä- 
sentieren. Somit kann aus einer Holomap ein Prozessmodell abgeleitet werden, 
welches den Austausch von Leistungen zwischen Akteuren (im Gegensatz zu lineari- 
sierten Funktionsschritten) in den Mittelpunkt stellt. 


Insgesamt stellt die Value Network Analysis eine diagrammatisch/tabellarische Technik zur 
Organisationsentwicklung mit dem Ziel von Prozessdefinitionen bzw. ausführbaren Prozes- 
sen dar, welche eine Abbildung von Interaktionsstrukturen auf kommunikationsorientierte 
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Ansätze wie S-BPM direkt unterstützt. Sämtliche Informationen werden dabei aus der 
Sicht von beteiligten bzw. verantwortlichen Rollenträgern generiert [4, 5, 6, 7]. 


5.1.4 Strukturierte Aktivsätze 


Im Folgenden wird eine Vorgehensweise beschrieben, die ausgehend von natürlich 
sprachlichen Beschreibung zu einem formalen Verhaltensmodell führt. Diese Vorgehens- 
weise orientiert sich an den Aktivsätzen von natürlichen Sprachen. Der Ablauf wird an 
Hand des Projekts Poly Energy Net (NET), einem vom Deutschen Bundesministerium 
für Wirtschaft und Energie geförderten Ansatz, eingeführt. In diesem Projekt galt es 
eine Lösung für ein sich selbst organisierendes verteiltes Energieversorgungssystem 
zu entwickeln. In den folgenden Abschnitten wird gezeigt, wie die dazugehörige Soft- 
ware entwickelt wurde, und zwar ausgehend von einer allgemeinen Beschreibung bis hin 
zu einem präzisen Modell, das dann in einer ersten Stufe auf Basis von Prozessspezi- 
fikationen in ein Programm umgesetzt wurde. 


5.1.4.1 Allgemeines 

Die in der Folge vorgestellten Schritte, die von einer informellen Beschreibung 
eines Prozesses zu einem formalen Modell des Ablaufs führen, müssen nicht in der 
angegebenen Reihenfolge ausgeführt werden. Die Schritte dienen vielmehr dem Ziel 
einer präzisen Prozessbeschreibung. Stellt sich in einem Schritt heraus, dass in einem 
vorangegangenen Schritt etwas vergessen wurde, oder stellt es sich heraus, dass es vor- 
teilhafter ist, Teilabläufe anders zu gestalten, so wird diese Änderung in dem momentan 
bearbeiteten Schritt aufgenommen. Diese Änderung wird nicht in den vorangegangenen 
Beschreibungen nachgezogen. Um einen ersten Entwurf einer Prozessbeschreibung zu 
erstellen, können die im vorangegangenen Kapitel beschriebenen Vorgehensweisen aus 
Design Thinking eingesetzt werden. 

Alle Dokumente der vorangegangenen Beschreibungen sind nach Abschluss 
einer detaillierteren Beschreibung standardmäßig obsolet und nicht mehr gültig, 
ausgenommen, in einer Beschreibung wird explizit darauf hingewiesen, dass eine 
vorangegangene Beschreibung noch gültig ist (z. B. als Übersichtsdokument). Erfah- 
rungsgemäß gelingt es, nicht mehrere Dokumente konsistent zu halten. Es sollte daher 
nur ein gültiges Dokument geben, sodass nach Abschluss der Vorbereitung ein formales 
Verhaltensmodell zur Verfügung stehen kann. Änderungen sollten in der Regel nur noch 
an diesem Modell vorgenommen werden. 

Bei der Erstellung eines Prozessmodells kann auch mit einem beliebigen Schritt 
begonnen werden. So können beispielsweise bei einer natürlich sprachlichen Beschreibung 
nur Aktivsätze verwendet werden. Damit fallen die Schritte, welche eine Beschreibung in 
beliebiger Form in eine aktive Beschreibungsform transformieren, weg. Es kann auch mit 
der Identifizierung der Handelnden begonnen und mit der Detaillierung jedes Handelnden 
fortgesetzt werden, einschließlich der Kommunikation mit anderen Handelnden. Die kon- 
krete Vorgehensweise hängt von den Umständen und den Vorlieben der Beteiligten ab. 
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5.1.4.2 Natürlich sprachliche Beschreibung der Prozesse 

Das Prozessgeschehen wird mehr oder minder strukturiert in natürlicher Sprache erzählt. 
Es gibt keinerlei Vorgabe hinsichtlich der Struktur des zu erstellenden Dokuments oder 
des zu verwendenden Vokabulars. Die Ersteller einer Prozessbeschreibung können 
ihren Vorlieben folgen. Das Bild (siehe Abb. 5.9) zeigt einen Textauszug aus der groben 
Anforderungsbeschreibung an das Energiemanagementsystem. 

Die anfängliche freie Verwendung der natürlichen Sprache erfordert von den 
Beteiligten keine speziellen Methodenkenntnisse. Die Erfordernis solcher Kenntnisse 
könnte eine große Hürde für das Einbinden von Betroffenen aus den verschiedenen 
Fachbereichen darstellen. 

Textuelle Beschreibungen können durch geeignete Bilder ergänzt werden. Das fol- 
gende Bild (siehe Abb. 5.10) zeigt eine funktionale Struktur des zu erstellenden Systems. 
Eine solche funktionale Struktur ist eine erste Annäherung an die Spezifikation eines 
Prozesssystems. 

Aufbauend auf diese mehr strukturellen Beschreibungen kann eine erste ablauf- 
orientierte Spezifikation erstellt werden. Einen Auszug einer Ablaufbeschreibung zeigt 
das folgende Bild (siehe Abb. 5.11). 


Das holare Modell 


. Das holare Modell ist ein logisches System, das sich in der realen Welt auf ein physikalisches System abbiklen lässt. 
$ Das gesamte Holare Versorgungssystem setzt sich aus Holonen zusammen. 
. Innerhalb jedes Holons wird zu jedem Zeitpunkt gleich viel Energie bereitgestellt („erzeugt“) wie verbraucht. 
. Holone bestehen aus Holaren (energetischen) Elementen. Dies sind: 
. holare Erzeugungs- und Verbrauchselemente 
*  holare Verbindungselemente 
$ holare Umwandlungselemente 
. holare Speicherelemente 
° holare Wächter. 
Alle holaren Elemente besitzen eine physikalische Instanzüerung. 
° Holare Elemente besitzen die Möglichkeit, mit mindestens einem Holonmanager zu kommunizieren. Sie sind mit 
maximal einem Holonmanager (zu einem holaren Objekt) verbunden.. 


° Holonmanager können über Steuersignale das Verhalten (z. B. Erzeugung, Verbrauch) von holaren Elementen 
beeinflussen. Alle holaren Elemente, die mit dem gleichen Holonmanager kommunizieren können, bilden ein Holares 
Objekt 

. In jedem Holon gibt es eine Instanz Holonkoordinator, die mit Holonmanagern im eigenen Holon und den 
Holonkoordinatoren in anderen Holonen kommunizieren kann. 

s Holare Objekte können existieren, ohne einem Holon angeschlossen zu sein. 

. Holare Elemente können existieren, ohne einem Holonmanager zugeordnet zu sein („freifiegende Holare Elemente“ 
Alle Holonmanager und Holonkoordinatoren besitzen eine physikalische Instanziierung. 

*  Holone können sich dynamisch nach bestimmten Holon-Regeln zu neuen Holonen zusammenschließen oder in kleinere 
Holone zerfallen. Die Umsetzung der Regeln erfolgt durch Holonkoordinatoren im Zusammenspiel mit Holonmanagern 

. Die Regeln für die Holonbiklung orientieren sich an logischen Erfordernissen und Rahmen-bedingungen. die durch die 
physikalische Instanzlierung der holaren Elemente bestimmt sind. 

. Holone können sich auflösen. Dies ist der Fall, wenn es keinen Holonkoordinator gibt. 

. Es gibt auch „nicht-holare* Elemente, das sind solche, die entweder keine Ansteuerbarkeit oder keine Verbindung zum 
energetischen System besitzen. 


Abb. 5.9 Anforderungen an ein Holares Energiemanagementsystem 
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Abb. 5.10 Funktionsblöcke eines Holaren Energiemanagementsystems 


im holaren System 
legen des Ausfalls des Ortsnetztrafos (im Beispiel A) kann ein einzelner Netzabschnitt im Niederspannungsbereich nicht mehr durch das übergeordnete 

|Mittelspannungsnetz versorgt werden. Erkannt wir dies durch Messen und Melden eines Spannungsabfalls auf nahe Null in dem betroffenen Netzabschnitt (vgl. 
PMU in Abb. 2 ). Dabei wird angenommen, dass die Vertellerschiene in der Ortsnetzstation intakt ist und lediglich der Trafo als solcher ausgefallen Ist. 
Leitstand bzw. Netzüberwacher melden das Ereignis „Spannungsabfall* automatisch an die Leitstelle, die mit einem weitestgehend durch automatisiertes Messen 
und Fernwirkung geprägten Prozess eine schnellstmögliche Versorgung (ggf. Minimalversorgung einiger Verbraucher) anstößt. 
Durch automatisches Abfragen von Messwerten (bei den PMUsim Netz) und sonstigen Fehlerinformationen (z. B. von den beteiligten Ortsnetzstationen) werden 

‚on der Leitstelle aus der Ort und soweit möglich die Ursache des Fehlers identifiziert. Im aktuellen Fall wird festgestellt, dass der Trafo bei A ausgefallen ist. 
Die Leitstelle informiert einen oder mehrere Holon-Manager (HM) bzw. Holon-Koordinatoren im betroffenen Netzgebiet. 
Die betroffenen Holon-Koordinatoren und Holon-Manager treten untereinander in Verbindung und verhandeln (auch mit benachbarten Holon-Koordinatoren) eine 
[Neubildung von Holonen, die eine Versorgung von möglichst vielen Verbrauchern auch ohne den defekten Ortsnetztrafo ermöglicht. Ziel ist eine solche Versorgung 
(auch ohne Netzersatzanlage) solange aufrechtzuerhalten, bis die defekten Teile der Ortsnetzstation ausgetauscht sind. 
Bei der in Abb. 2 skizzierten Situation kann angenommen werden, dass vom Holon-Management der Leitstelle die folgende Neubildung vorgeschlagen wird (vgl. 
Abb. 3): 
. Die holaren Leitungen sind wie folgt zu schalten: 

° Der Schalter 4 ist zu schließen und verbindet somit die zuvor vom nun defekten Trafo versorgte Verteilschiene in der Ortsnetzstation A zu versorgen. 

° Durch Öffnen bzw. Schließen der Schalter 5, 6, und 7 entsteht eine vom Rest des Systems abgetrennte Insel. 

° Durch Öffnen bzw. Schließen der Schalter 8 - 11 entsteht eine vom Rest des Systems abgetrennte Insel. 

Es werden folgende Holone gebildet: 

° Die durch Schalter 6 und 7 abgetrennte Insel bildet Holon C und versorgt sich selbst. Abgesehen von einer häuslichen PV-Anlage ist die einzige 
Versorgungsquelle das BHKW, das als „Notstromaggregat” für einen sehr kritischen Verbraucher vorgehalten wird. Das Holon istso zu betreiben, 
dass letzteres stets vollversorgt Ist; weitere Verbraucher können nur eine Minimalversorgung erwarten. 

(NB: Sollte diese Versorgungssituation nicht aufrechterhalten werden können, würde Holon C vermutlich bald in kleinere, teils sehr schlecht versorgt 
Holone zerfallen oder ein Teil der Verbraucher würde dem Holon A zugeschlagen werden.) 

° Die durch Schalter 8 und 11 abgetrennte Insel bildet Holon B und versorgt sich selbst. Hier ist eine weitgehende Vollversorgung zu erwarten, da es 
im Holon leistungsfähige Erzeige (großes BHKW, Freiflächen-PV-Anlage, Quartiersspeicher) gibt. 

° Alle anderen Holaren Elemente bilden Holon A. Abgesehen von einem kleineren BHKW und wenigen häuslichen PV-Anlagen und zugehörigen 
häuslichen Speichern sichert die Ortsnetzstation B die Versorgung. 

Wenn die Leitstelle diese Holonbildung akzeptiert, veranlasst sie die entsprechenden Schaltvorgänge und Einstellungen. 

Das Betriebspersonal wird informiert, fährt zur Ortsnetzstation und trennt den defekten Trafo von der Verteilerschiene. 

Die durch die durch die Holon-Bildung herbeigeführte Situation erlaubt bei ausreichend vorhandener Energiequellen (Sonne, Gas) eine optimale, weitestgehend 
olle Versorgung aller Verbraucher, bis eine Ersatztrafo installiert bzw. der bestehende Repariert werden kann. 

NB: Sollte eine Versorgung wie durch die Holon-Neubildung herbeigeführt, nicht möglich sein, wird dies als Fehlersituation erkannt und es wird eine neue 

|Holonbildung angestoßen. Als ultima ratiowürde auch hier eine Netzersatzanlage zum Einsatz kommen. 

Nach Beseitigung des Fehlers wird durch das Betriebspersonal vor Ort unter Einbezug der Netzleitstelle der Normalzustand (Trafo versorgt die Verteilschiene in der 

Ortsnetzstation A) wieder hergestellt. 

Die Messung in der Leitstelle erkennt, dass ein neuer, starker Versorger zur Verfügung steht, und stößt eine Neubildung von Holonen an. 

NB: Diese dürfte mit hoher Wahrscheinlichkeit wieder die Situation mit den Holonen A und B vor Eintritt des Use-Case herbeiführen. 


Abb. 5.11 Dynamik eines Holaren Managementsystems 
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Ergänzt wird diese Ablaufbeschreibung durch eine Illustration der Auswirkungen auf 
ein holares Energienetz. In der obigen Abbildung wird auf einige Elemente (Schalter) im 
folgenden Bild (siehe Abb. 5.12) verwiesen. 

Die am Anfang verwendeten Werkzeuge für eine erste Anforderungsdefinition und 
Ablaufspezifikation sind nicht strukturiert. Es können einfach Texte und ergänzende 
Zeichnungen beliebiger Art verwendet werden. In den nachfolgenden Schritten wird 
diese unschematische Beschreibung eines Prozesses Zug um Zug in eine präzise Ablauf- 
beschreibung überführt. 


5.1.4.3 Prozessbeschreibungen in Aktivform 

Informelle Prozessbeschreibung in natürlicher Sprache enthalten sehr oft Passivsätze 
(siehe auch obige Ablaufbeschreibung). Passivsätze enthalten allerdings keine direkte 
Aussage über den Ausführenden einer Aktion. Passivsätze werden dann verwendet, wenn 
der Ausführende einer Aktion nicht wesentlich ist. Allerdings ist dies bei Prozessen nicht 
gegeben. Prozessbeschreibungen müssen den Ausführenden einer Handlung enthalten. 
Es gilt nun alle Passivsätze in Aktivsätze umzuwandeln. Dazu müssen zunächst die akti- 
ven Elemente identifiziert werden. Aktive Elemente können Menschen, Softwaresysteme 
die automatisch ablaufen und bestimmte Aktivitäten ausführen, physikalische Systeme 
oder beliebige Kombinationen aus diesen Grundelementen sein. So kann in unserem 
Beispiel die Leitstation eine Kombination aus Software, Menschen und elektrischen 
Systemen sein. Die Software fordert einen Bediener auf einen bestimmten Messwert 
abzulesen und ihn einzugeben. Die Software veranlasst abhängig vom eingegebenen 
Messwert, dass ein Schalter geschlossen wird. 


2. 


geschlossene 
Trennstelle 


Abb. 5.12 Beispiel eines Holaren Energiemanagementsystems (Quelle: B.A.U.M.) 
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Um zu vermeiden, dass eine Prozessbeschreibung zu sehr vom organisatorischen und 
technischen Umfeld abhängig ist, werden abstrakte Handelnde eingeführt. Solche abs- 
trakte Handelnde sind Entitäten, die Nachrichten senden, empfangen oder interne Tätig- 
keiten ausführen. Das folgende Bild (siehe Abb. 5.13) zeigt das Funktionsdiagramm mit 
zugeordneten aktiven Elementen. Diese abstrakten aktiven Elemente werden als Subjekte 
bezeichnet, in Anlehnung an die Subjekte in Aktivsätzen. Subjekte sind die Rollen in 
Prozessen. 

Die Aufgaben der identifizierten Subjekte können für ein besseres Verständnis wie in 
Tab. 5.2 gezeigt kurz beschrieben werden. 

Durch die Einführung von Handelnden in Form von Subjekten können nun alle 
Passivsätze durch entsprechende Aktivsätze ersetzt werden. Damit wird die Prozess- 
beschreibung vollständiger. Das folgende Bild (siehe Tab. 5.3) zeigt eine Prozess- 
beschreibung mit Aktivsätzen in Tabellenform. Die Nummerierung der Sätze gibt bereits 
den Kontrollfluss wider. Die Nummer der Nachfolgeaktion wird in der so benannten 
Spalte angegeben. Hängt die Nachfolgeaktion von bestimmten Ergebnissen der Aktion 
ab, wird diese Bedingung in der Spalte Nachfolgeaktion mit beschrieben. Abhängig von 
der gültigen Bedingung kann es eine andere Nachfolgeaktion geben. 

Eine Tabelle mit dem Kontrollfluss eines Prozesses kann der Ausgangspunkt für ein 
kontrollflussorientiertes Prozessmodell sein. Die einzelnen Handelnden sind die Swim Lanes 
in BPMN bzw. in einer Swim-Lane-orientierten EPK oder in UML-Zustandsdiagrammen. 


+ — Informationsfluss 
+ Trigger 


Abb. 5.13 Subjektorientierte Betrachtung eines Holaren Energiemanagementsystems 
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. | Handlung 


Hinweise 


1. | Netzüberwacher stellt Spannungs- 
abfall im Niederspannungsnetz fest 


Nach-folge-aktion 


Nutzt dafür Funktionen aus der 2 
Funktionsgruppe „Messen“ 


2. | Netzüberwacher meldet die 3 
Situation an Leitstelle 
3. | Leitstelle identifiziert und lokalisiert | Nutzt dafür Funktionen aus den 4 


den Fehler 


Funktionsgruppen „Überwachen“ 
und „Messen“ (Bemerkung: Was 
passiert wenn Leitstelle den Fehler 
nicht identifizieren kann?) 


„alert“ und wartet auf Rückmeldung 


4. | Leitstelle informiert Holon- Achtung: hier kann ein single- 5 
Manager (HM) bzw. Holon- point-of-failure bzw. Engpass 
Koordinatoren im betroffenen vorliegen; ist ggf. durch einen 
Netzgebiet dezentralen Mechanismus zu 

ersetzen 

5. | (sofern angesprochen) Holon- Nutzt dafür Funktionen 6 
Koordinatoren treten mit Holon- aus der Funktionsgruppe 
Managern in den betroffenen (Holonmanagement) 

Holonen in Verbindung 

6. | (sofern kein Holon-Koordinator 7 
tätig wird) Holon-Manager 
identifizieren einen HM, der die 
Koordinationsaufgabe übernimmt 

7. \Holon-Koordinator und betroffene | Nutzt dafür Funktion „Holonbil- |8 
Holon-Manager ermitteln eine dung“ aus der Funktionsgruppe 
plausible neue Holon-Konstellation | „Holonmanagement“ 

8. | Holon-Koordinator meldet den 8 
errechneten Vorschlag an die 
Leitstelle 

9. |Holon-Koordinator geht in Zustand 10 


von der Leitstelle 


Allerdings sollten diese Modellierungsmethoden nur verwendet werden, wenn in einem Pro- 
zess keine asynchronen Ereignisse wie z. B. die Möglichkeit Bestellungen zu ändern vor- 
kommen, und die Parallelität der Handelnden nicht modelliert werden soll. Darüber hinaus 
sollte die Anzahl der Handelnden nicht zu hoch sein. 

Swim Lane-Darstellungen sind in der Regel flach, d.h. es gibt keine Hierarchien 
von Swim Lanes. Eine größere Anzahl als fünf Swim Lanes führt zu unübersichtlichen 
Darstellungen. So hat ein Service Prozess mindestens die Swim Lanes Kunde, Call 
Center, First Level Support, Abrechnung und gegebenenfalls Kundenrückmeldung. Die 
Erfahrung zeigt, dass in realen Prozessen in der Regel etwa 10 Handelnde und mehr 
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involviert sind. Unübersichtlich werden Swim Lane Diagramme auch dann, sobald der 
Kontrollfluss mehrere Swim Lanes kreuzen muss, um in eine andere Swim Lane zu 
wechseln. 

Bei organisations- oder unternehmensübergreifenden Prozessen in einem ver- 
teilten Umfeld sind Kontrollflüsse keine handhabbare Darstellung. In einer verteilten 
Umgebung sind Nachrichten die anschaulichere Art die Zusammenarbeit von einzelnen 
Handelnden zu modellieren. 


5.1.4.4 Tabellarische rollenorientierte Beschreibung 

Im letzten Schritt vor der eigentlichen Prozessmodellierung wird die Prozess- 
beschreibung entsprechend der Handelnden strukturiert. Alle Sätze mit denselben Han- 
delnden als Subjekt werden in einer Tabelle zusammengefasst. Dazu kann es notwendig 
sein, dass die Prozessbeschreibung mit Interaktionen zwischen Subjekten ergänzt werden 
muss. Phrasen wie „informiert Subjekt xy“ oder „tritt in Verbindung mit“ usw. werden 
ersetzt durch Sende und Empfangsaktionen (siehe Tab. 5.4). Der Satz 2 „Netzüberwacher 
meldet Situation an Leitstelle“ im Bild in Abschn. 5.1.4.3. wird in eine Sende und eine 
Empfangsaktion umgewandelt. Im folgenden Bild entspricht dies der Aktion 2 (Netz- 
überwacher sendet Status-Schwarz an Leitstand“ im Tabellenabschnitt für den Netzüber- 
wacher. Das Gegenstück dazu ist der Satz Nr. 1 im Tabellenabschnitt Leitstand. 

Nach dem Erstellen der Verhaltenstabellen kann ein formales Modell in einer 
geeigneten Modellierungssprache abgeleitet werden. Es sollte dabei eine Sprache ver- 
wendet werden, in der die für wichtig erachteten Aspekte des betrachteten Prozes- 
ses anschaulich und präzise ausgedrückt werden können. In unserem Beispiel haben 
wir S-BPM ausgewählt. Abb. 5.14 zeigt in der linken Hälfte die Netzwerkstruktur 
des betrachteten Prozesses. Die Rechtecke mit den abgerundeten Ecken stellen die 
beteiligten Handelnden dar. Die Pfeile zwischen den Handelnden sind mit den aus- 
getauschten Nachrichten beschriftet. Die Zahlen an den Nachrichtennamen entsprechen 
den Satznummern in der obigen Tabelle. 

Das Diagramm rechts neben der Prozessstruktur zeigt das Verhalten des Subjekts 
Holonkoordinator. Die Kreise mit den Buchstaben E und S sind Kommunikations- 
zustände. Übergänge von Kreisen mit einem E sind mit den in diesem Zustand 
erwarteten Nachrichten beschriftet. Die Übergänge nach S-Zuständen sind mit den in 
diesem Zustand gesendeten Nachrichten beschriftet. Alle anderen Übergänge definieren 
lokale Operationen auf lokalen Daten. 


5.1.5 Prozessmodellierung 


5.1.5.1 Auswahl der Modellierungssprache 

In der Folge werden exemplarisch einige Faktoren angeführt, welche die Auswahl einer 
geeigneten Modellierungsnotation bzw. -sprache erleichtern sollen. Dazu zählen die 
Rahmenbedingungen eines BPM-Vorhabens, die Handhabbarkeit der Sprache sowie die 
Unterstützung der nachgelagerten Aktivitäten wie Validierung [8, 9, 10, 11, 12]. 
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Tab. 5.4 Ablauf im Holaren System (Präziser) 

Nr. | Subjekt Prädikat Objekt Indirektes Ergebnis Weiter 
(Akteur) Objekt bei 


Netzüberwacher 


1 | Netzüberwacher | Misst Niederspan- Spannungs- |2 
Spannung im |nungsnetz abfall 
Spannungs- |3 
anstieg 
2  |Netzüberwacher | Sendet (1) Status- An Leitstand Gesendet 1 
Schwarz (Leitstelle) 
3 | Netzüberwacher | Sendet (10) Status- An Leitstand Gesendet 1 
Grün (Leitstelle) 
Leitstand 
1 |Leitstand Empfängt (1)Status- Von Netzüber- | Empfangen 2 
meldung wacher 
2  |Leitstand Identifiziert den Fehler Fehler 3 
und lokalisiert gefunden 
Fehler nicht |? 
gefunden 
3  |Leitstand Sendet (2) Status An* Holon- Gesendet 4 
Koordinatoren 
4 |Leitstand Empfängt (5) Vorschlag | Von* Holon- 5 
Koordinator 
Leitstand Prüft Vorschlag Angenommen | 6 
Leitstand Sendet (6) V-Ange- An* Holon- 
nommen Koordinatoren 


Bezüglich Rahmenbedingungen interessiert vor allem die Frage ‚Was sind die 
Eigenschaften des zu modellierenden Sachverhalts?‘ Bestimmend für die Auswahl 
einer Modellierungssprache sollten vor allem die folgenden Eigenschaften eines 


Sachverhalts sein: 


e Asynchrone Ereignisse: Liegen derartige Ereignisse vor, dann sollte eine ent- 
sprechende Modellierungssprache die Möglichkeit bieten, die damit verbundene 
Parallelisierung von Prozessen oder Prozessschritten derart abzubilden, dass 
gegebenenfalls eine Ausführung die Parallelität widerspiegelt. Dies bedeutet, dass 
die Modellierungssprache Konstrukte zur Darstellung asynchroner Ereignisse enthält, 
welche diese zeitliche Qualität explizit enthält. Damit kann zur Ausführungszeit ent- 
sprechend eine Laufzeitumgebung konfiguriert werden. 
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Netzüberwachung 


(1) Status-Schwarz 
(10) Status-Grün 


| 


Leitstelle 


Internes Verhalten des 
Holonkoordinators 


(8) Reparaturauftrag 


Reparaturabteilung (2) Status von Leitstelle 


(9) bevorstehenden © 
Wiederanschluss 


go Spannungsabfall an alle HolonManager ] 


(2) Status 
(6) V-Angenommen 
(7) Umsetzungsbestätigung 


(5) Vorschlag 


g E-Schwarz von allen HolonManager] 


ermittle Holonkonstellation 
Konstellation ermittelt 


Holon 1...n 


Holares Objekt 1 
(Holonkoordinator) 


(3) Spannung 


(5) Vorschlag an Leitstelle 


(7) Umsetzungsbestätigung von Leitstelle 


freuen 


Holares Objekt 
n 


i 


HolonManager 


Abb. 5.14 Verhaltensbeschreibung des Subjekts Holonkoordinator 


e Organisations- und unternehmensübergreifend: Ist ein Sachverhalt nicht nur für eine 
bestimmte Organisation oder deren Einheit, sondern auch für vernetzte Partner rele- 
vant, die außerhalb der unmittelbaren Tätigkeitsbereiche liegt, wie beispielsweise in 
der Zulieferindustrie, dann sollten ausgewiesene Modellierungsmechanismen oder 
Sprachkonstrukte zur Verfügung stehen, welche eine Kapselung organisationsexterner 
Sachverhalte ermöglicht. Damit wird eine Einbettung externer Akteure einer Organi- 
sation möglich, ohne im Detail deren Abläufe kennen und repräsentieren zu müssen. 

e Anzahl der Handelnden: Diese Kenngröße scheint auf den ersten Blick nicht 
unbedingt relevant für die Auswahl einer Modellierungssprache. Sie gewinnt aller- 
dings an Bedeutung, wenn es zum einen um die Komplexität von Prozessen geht, 
und zum anderen um die Verständlichkeit der Modelle. Schließlich spielt auch die 
Instanz-Modellbeziehung in diesen Faktor herein. Besteht eine Vielzahl an han- 
delnden Akteuren, dann sollte eine Notation auch Modellierungsmechanismen oder 
Sprachkonstrukte aufweisen, welche diese sowohl sichtbar macht, als auch aggregiert 
oder mittels anderer Perspektiven (z. B. Funktionssicht) zugänglich macht. 
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Bezüglich Handhabbarkeit interessiert vor allem die Frage ‚Wie soll der Sachverhalt 
beschrieben werden?‘ Bestimmend für die Auswahl einer Modellierungssprache sollten 
vor allem die folgenden Eigenschaften bzw. Qualität einer Modellierungssprache sein: 


e Anzahl der Symbole: Die Anzahl der Symbole kann zum einen mächtige Modelle ein- 
fach überschaubar gestalten lassen, aber zum anderen eine unerwünschte Verkürzung 
von Sachverhalten mit sich bringen. 

e Definition der Symbole: Der Gebrauch der Symbole sollte eindeutig, d. h. objektiv 
nachvollziehbar für Modellierende sein. Dies erleichtert die Effektivität und Effizienz 
bei der Erstellung von Modellen. 

e Verfügbarkeit der Werkzeuge zur Modellbeschreibung: Die Verfügbarkeit von digita- 
len Werkzeugen zur einfachen und korrekten Darstellung von Sachverhalten bestimmt 
die Gebrauchstauglichkeit einer Modellierungssprache mit. Ein Syntaxeditor bei 
diagrammatischen Sprachen hilft beispielsweise, syntaktisch korrekte Modelle zu 
erstellen sowie umfangreiche Sachverhalte gebrauchstauglich zu strukturieren. 

e Möglichkeiten der Hierarchisierung von Modellen: Diese Eigenschaft erlaubt, ver- 
netzte Sachverhalten aus einer top-down Perspektive zu erschließen. Dadurch wird 
üblicherweise die Lesbarkeit von Modellen erleichtert und damit die Verständlichkeit 
abgebildeter Sachverhalte für nicht unmittelbar Beteiligte erhöht. 


Bezüglich Unterstützung weiterer Aktivitäten interessiert vor allem die Frage ‚Wie ist die 
Unterstützung des Modells für nächste Schritte?‘ Für die Auswahl einer Modellierungs- 
sprache sollten in diesem Kontext vor allem die folgenden Features einer Modellierungs- 
sprache betrachtet werden: 


e Validierungswerkzeuge: Kann ein Modell validiert werden? Dies bedeutet, dass 
mittels eines Werkzeugs festgestellt werden kann, ob die Notation und damit alle ver- 
wendeten Sprache im Sinne der Syntax der Sprache sowie im Sinn der Intention des 
abgebildeten Sachverhalts korrekt verwendet wurden. 

e Optimierungswerkzeuge: Kann ein Prozess mithilfe seines Modells optimiert werden? 
Die Optimierung ist der erstmaligen Modellierung und Validierung nachgelagert und 
zielt auf die optimale Verteilung von Aufgaben und optimale Nutzung von Ressourcen 
ab. So soll mittels eines Werkzeugs festgestellt werden können, ob die Notation und 
damit alle verwendeten Sprachen die Optimierung von modellierten Prozessen durch 
entsprechende Konstrukte der Sprachen oder durch spezielle Mechanismen zulässt 
bzw. aktiv (etwa durch Vorschläge oder Referenzmodelle) unterstützt. 

e Werkzeuge für die organisatorische Einbettung: Kann die Integration eines modellier- 
ten Prozesses in eine Organisation mithilfe eines Werkzeugs realisiert werden? Dieser 
Schritt ist der erste zur Implementierung von Prozessen und erfordert, dass mittels eines 
Werkzeugs bestimmte werden kann, welche Aufgaben- oder Rollenträger bzw. welche 
Organisationseinheiten den abgebildeten Sachverhalt in der Praxis ausführen können 
sollen. Auf dieser Basis kann danach entsprechende Zuordnung zur organisationalen 
Umsetzung von Prozessmodellen getroffen (und nach Bedarf wieder geändert) werden. 
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e Werkzeuge für die technische Einbettung: Kann die Integration eines modellierten 
Prozesses in eine (informations-)technische Infrastruktur bzw. Informationssystem- 
architektur mithilfe eines Werkzeugs realisiert werden? Dieser Schritt ist der zweite 
erforderliche zur Implementierung von Prozessen und bedarf der Bestimmung mit- 
tels eines Werkzeugs, welche technischen Systems den abgebildeten Sachverhalt in 
der Praxis ausführen können. Auf dieser Basis kann danach entsprechende Zuordnung 
zur technischen Umsetzung von Prozessmodellen getroffen (und nach Bedarf wieder 
geändert) werden. 

e Werkzeuge für die Inbetriebnahme und den Betrieb: Können die Inbetriebnahme und 
der Betrieb eines modellierten Prozesses in einer Organisation mithilfe eines Werk- 
zeugs unterstützt bzw. sichergestellt werden? Dieser Schritt ist erforderlich, sobald 
ein Prozess ‚produktiv‘ geschaltet wird, d. h. nach seiner organisationalen und tech- 
nischen Implementierung in den operativen Betrieb einer Organisation überführt 
bzw. in deren operativen Praxis wirksam wird. In diesem Kontext sollte ein Werk- 
zeug helfen, die Einführungsphase eines modellierten Prozesses zu unterstützen, also 
etwa die Reihenfolge festzulegen, welche Prozessschritte in welcher Reihenfolge in 
den operativen Betrieb übernommen werden. Ein entsprechendes Werkzeug sollte 
auch die Überwachung des Einsatzes von implementierten Prozessen unterstützen 
und so helfen. den operativen Betrieb einer Organisation sicherzustellen und deren 
Weiterentwicklung effektiv zu unterstützen. Letzteres kann etwa durch Annotation an 
Prozessmodellen, welche Ausführungshindernisse markieren, erfolgen. 


5.1.5.2 Modellierung durch Konstruktion 

Bei der Konstruktion eines Prozessmodells beginnt die Modellierung mit einem „leeren 
Blatt Papier“. Mit den Informationen aus der Prozessanalyse wird Schritt für Schritt der 
Prozess beschrieben. Die erforderlichen Aktivitäten umfassen, abhängig vom gewählten 
Ansatz, mehrere Aktivitäten: 


e Beschreibung der Prozesse mit ihren Beziehungen (Prozessnetzwerk) 

e Identifikation des zu beschreibenden Prozesses 

e Identifikation der an dem Prozess beteiligten Akteure bzw. Systeme 

e Festlegen der zwischen den Akteuren bzw. Systemen ausgetauschten Informatio- 
nen im Rahmen des Kontroll-, Daten- und Nachrichtenflusses zur Bearbeitung von 
Geschäftsfällen. Dies inkludiert auch die Umsetzung von Geschäftsregeln, da sie das 
Verhalten von Akteuren und Systemen unmittelbar beeinflussen. 

e Beschreiben des Verhaltens der einzelnen Akteure bzw. Systeme, insbesondere durch 
Funktionsschritte und deren zeitlich-kausalem Zusammenhang entsprechend dem 
modellierten Sachverhalt. 

e Definition der Geschäftsobjekte bzw. Daten und deren Verwendung. 


Diese Aktivitäten werden entsprechend der ausgewählten Sprache in einer bestimmten 
Reihenfolge gesetzt und führen dem entsprechend zu unterschiedlich detaillierten Dar- 
stellungen von Sachverhalten. 
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5.1.5.3 Modellierung durch Restriktion 

Neben der Modellierung durch Konstruktion gibt es grundsätzlich noch die Möglich- 
keit der Modellierung durch Restriktion. Dabei wird von allgemeinen Prozessmodellen 
ausgegangen. Ein typisches Beispiel ist der kommunikationsorientierte Zugang, wie bei 
S-BPM verfolgt. Im universalen Prozessmodell kann jeder an einem Prozess beteiligte 
Akteur bzw. System an jedes andere beteiligte System bzw. jeden anderen Akteur jeder- 
zeit eine Nachricht senden bzw. von diesem empfangen. 

Diese Nachricht hat den allgemeinen Namen ‚Nachricht‘ und kann als Geschäfts- 
objekt beliebige Medien übertragen. Das Ergebnis ist ein Universalprozess, der durch 
die Anzahl seiner Subjekte gekennzeichnet ist. Diese werden als Kästen mit Subjekt 1..n 
gekennzeichnet. Deren wechselseitige Interaktionsmöglichkeiten werden durch vorab 
gesetzte Pfeile zwischen den Subjekt-Kästchen gekennzeichnet. Daraus resultiert für 
jedes Subjekt ein gleichartiges initiales Verhalten. 

Im Rahmen der Modellierung durch Restriktion wird in folgenden Schritten zu einem 
detaillierten Sachverhalt vorgegangen: i) Anzahl der Subjekte und Subjektbezeichner 
bestimmen, ii) Kommunikationspfade reduzieren; iii) Nachrichtentypen spezifizieren, iv) 
Verhalten der Subjekte spezifisch anpassen, v) Geschäftsobjekte spezifizieren und verfeinern. 

Werden andere, etwa funktionsorientierte Ansätze gewählt, dann können grundsätz- 
liche Strukturen verallgemeinert, etwa in Form von Referenzmodellen, zur Verfügung 
gestellt werden. Dabei werden auch verhaltensorientiere Muster zum Einsatz kommen, 
etwa vorangegangene Ereignisse zu Funktionen oder Bedingungen, die nach Abarbeiten 
einer Funktion den weiteren Verlauf von Geschäftsprozessen bestimmen. 


5.1.5.4 Kombination 

Während bei der Konstruktion von Prozessmodellen die Modellierung mit einem „leeren 
Blatt Papier“ beginnt, und um Informationen aus der Prozessanalyse Schritt für Schritt 
erweitert wird, wird bei der Modellierung durch Restriktion von einer verallgemeinerten 
Struktur von Prozessmodellen und deren Bestandteile ausgegangen. Ein typisches Bei- 
spiel einer Kombination beider Ansätze stellt der Fall dar, der dem ‚middle-out‘ Ansatz 
entspricht. Eine Instanz dieses Falls ist, mit einer Konstruktion zu beginnen, und sobald 
ein (wiederkehrendes) Muster auftritt, ein Referenzmodell zum Einsatz zu bringen und 
zu reduzieren bzw. zu konkretisieren. 

Weitere Anwendungsinstanzen wären ein Mustervergleich sowie der Start mit wieder- 
kehrenden (Routine-)Prozessen. Letztere kehren den obig genannten Fall um, und 
erlauben, spezielle Ausprägungen von Prozessverläufen in generalisierte Prozessarchi- 
tekturen einzubetten. Der Mustervergleich hingegen stellt eine Art Kontrollvorgang dar, 
wobei mittels eines verallgemeinerten Musters die Vollständigkeit bzw. Korrektheit eines 
Modells überprüft werden kann. 
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5.2 _  Qualitätskontrolle: Validierung und Optimierung 


Die Validierung steht in enger Beziehung zur Modellierung. In der Modellierung wird 
der Prozessablauf entsprechend der Zielsetzung beschrieben, Dies bedeutet, dass wäh- 
rend der Modellierungstätigkeit folgernde die Frage mitschwingt: ‚Entspricht das Modell 
den gesetzten qualitativen und quantitativen Zielen? Die Prüfung, ob ein Prozessmodell 
den gesetzten Zielen entspricht, wird als Validierung bzw. Optimierung bezeichnet. 
Somit laufen während der Modellierung permanent Validierung und Optimierung mit. 
Nach der Entscheidung die Modellierung abzuschließen, ist wird nun abschließend 
geprüft, ob das Gesamtmodell den gesetzten Zielen entspricht. 

Eine Validierung zeigt, ob der Prozess alle Anforderungen erfüllt und die 
beabsichtigten Ergebnisse erreicht. Wesentlich ist für einen Prozess auch ob damit die 
gewünschten Ergebnisse mit dem geringsten möglichen Aufwand erreicht werden. Die 
Qualitätskontrolle bei Geschäftsprozessen hat also zwei wesentliche Aufgaben. Sie soll 
die Effektivität und die Effizienz von Prozessen prüfen. Effektivität bedeutet, dass der 
Prozess die an ihn gestellten Anforderungen erfüllt, d. h. das gewünschte Ergebnis (Out- 
put) liefert. Effizient ist der Prozess dann, wenn dieser mit möglichst geringem finanziel- 
len und zeitlichen Mitteleinsatz ausgeführt werden kann, um das gewünschte Ergebnis 
zu liefern. Dies soll durch die Optimierung erreicht werden. 

Diese Qualitätskontrollen müssen möglichst frühzeitig einsetzen, und zwar bevor 
IT-Systeme aufwendig entwickelt und die späteren Anwender geschult werden. Das fol- 
gende Bild (siehe Abb. 5.15) fasst die einzelnen Aspekte der Validierung und Optimierung 
zusammen. Die Überprüfung eines Prozessmodells wird durch entsprechende Werk- 
zeuge und Referenzmodelle unterstützt. Für die Validierung gibt es manuell Hilfsmittel 
wie z. B. Checklisten oder Rollenspiele, während für die Optimierung Simulationssoft- 
ware eingesetzt werden muss. Die Ergebnisse der Überprüfung werden aufbereitet und 
in ToDo-Listen zur Abarbeitung eingetragen, d.h. es wird erneut mit Modellierungs- 
aktivitäten gestartet. Dieser Zyklus wiederholt sich, bis die Überprüfung zu einem als gut 
genug betrachteten Ergebnis führt. 
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Abb. 5.15 Struktur der Qualitätssicherung eines Prozessmodells 
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5.2.1 Validierung 


Voraussetzung für die Validierung ist ein Modell, das den zu repräsentierenden Sach- 
verhalt wiedergibt. Es wird überprüft, ob das Modell das erwartete Ergebnis gemäß den 
spezifizierten Qualitätsmerkmalen liefert, und ob der Prozess zur Erreichung der Ziele 
des Unternehmens beiträgt. Dieser Aspekt wird als semantische Richtigkeit bezeichnet. 
Diese ergibt sich aus dem Konsens der Führungskräfte sowie der Fach- und Methoden- 
experten, die das Modell als zutreffend erachten. 

Von der semantischen Richtigkeit ist die syntaktische Gültigkeit abzugrenzen, 
welche die Einhaltung der festgelegten Beschreibungsregeln betrifft, d.h. sind die 
Beschreibungsmittel entsprechend der Vorgaben zur Modellierungssprache eingesetzt. 


5.2.1.1 Manuelle Prozessvalidierung 
Das folgende Bild (siehe Abb. 5.16) zeigt eine allgemeine Vorgehensweise bei der manu- 
ellen Validierung. Hier wird mithilfe von Checklisten die Prozessdokumentation überprüft. 
Die Prozessdokumentation umfasst die Beschreibung der Ziele, Inputs, Ergebnisse, aus- 
lösende Ereignisse und natürlich das Modell des Prozesses. Die Prozessdokumentation soll 
von allen betroffenen Parteien eines Prozesses an Hand der Checklisten überprüft werden. 
Die Befunde der einzelnen Parteien werden konsolidiert und in einem gemeinsamen 
Workshop geklärt sowie gemeinsam die notwendigen Überarbeitungen festgelegt. Dieser 
Zyklus wiederholt sich bis gemeinsam entschieden ist, dass keine weiteren Überarbeitungen 
mehr notwendig mehr sind. 
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Abb. 5.16 Ablauf einer manuellen Prozessprüfung 
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Zur Vorbereitung eines Reviews wird die Prozessbeschreibung und eine Checkliste, 
nach der die Prozessbeschreibung geprüft werden soll, kommuniziert. Diese Checkliste 
enthält Fragen, die die Gutachter bezüglich des Prozesses beantworten sollen. 

Beispiele für solche Fragen sind: 


e Unterstützt der Prozess die Ziele des Unternehmens? 

e Sind die Ziele des Prozesses definiert? 

e Ist der Nutzen des Prozesses in der Zielsetzung klar beschrieben und ist ersichtlich, 
welche Wertschöpfung er für wen liefert? 

e Welche Risiken birgt der Prozess? 

e [st ein Prozessverantwortlicher (Process Owner) benannt? 

e Sind die Befugnisse des Prozessverantwortlichen (Process Owner) festgelegt und sind 
diese ausreichend? 

e Gibt es Kennzahlen, mit denen die Zielerreichung bewertet werden kann? 

e Sind die Messverfahren für die Kennzahlen eindeutig festgelegt? 

e Werden die Zielwerte für die Kennzahlen des Prozesses systematisch festgelegt und 
liefern sie eine Aussage über den Wertbeitrag des Prozesses? 

e Unterstützt der Prozess die Politik und Strategie des Unternehmens bzw. der IT- 
Organisation? 

e Ist der Prozessablauf beschrieben? 

e Sind die Eingaben und Ergebnisse des Prozesses beschrieben? 

e Ist klar, wer (Organisationen, Rollen, Personen) welche Eingaben liefert und welche 
Ergebnisse entgegennimmt? 

e Werden die Beschreibungskonventionen für Prozesse eingehalten? 

e Ist definiert, wer für die einzelnen Schritte des Prozesses verantwortlich ist (Organisa- 
tionen, Rollen oder Personen)? 

e Ist das Vorgehen in dem Prozess auf die Interessensgruppen (beispielsweise Kunden) 
ausgerichtet? 

e Ist das Vorgehen im Prozess klar begründet? 

e Gibt es neben der Prozessbeschreibung noch ausreichend Hilfsmittel für die Aus- 
führung des Prozesses (Checklisten, Arbeitsanweisungen etc.)? 

e Ist der Geltungsbereich des Prozesses eindeutig festgelegt? 

e Sind die Beziehungen des Prozesses zu anderen Prozessen beschrieben bzw. definiert? 


Die obige Frageliste ist nur exemplarisch und nicht vollständig. In Unternehmen werden 
Fragelisten mit bis zu 100 Fragen verwendet. 

Das Lesen von umfangreichen Prozessdokumentationen und deren Abgleich mit lan- 
gen Checklisten ist sehr ermüdend. Die Erfahrung zeigt, dass mit zunehmender Seiten- 
zahl die Intensität der Prüfung nachlässt. Die ersten Seiten werden noch genau gelesen. 
Dann nimmt die Genauigkeit immer mehr ab. Um die Schwächen einer visuellen 
Begutachtung zu kompensieren, wurde eine stärker formalisierte Version des Reviews 
entwickelt, der „Walk Through“, der sich überwiegend auf das Prozessmodell bezieht. 
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5.2.1.2 Walk Throughs 

Ähnlich wie bei der Code Inspection in der Programmierung, wird beim Walk 
Through ein Prozess gemeinsam mit ausgewählten Prozessbeteiligten Schritt für 
Schritt besprochen. Um das schrittweise Durchgehen lebendiger zu gestalten, kann 
eine formale Prozessbeschreibung mithilfe eines praktischen Beispiels durchlaufen 
werden. Ein Prozessbeteiligter geht anhand eines konkreten Beispiels die Geschäfts- 
prozessbeschreibung schrittweise durch. Zu jedem Prozessschritt stellt ein Experte 
gezielte Fragen, um die Effektivität der Prozessbeschreibung zu hinterfragen. 

Es werden beispielsweise das Verständnis der Fachbegriffe, die fachliche Notwendig- 
keit sowie die Vollständigkeit der Prozessbeschreibung hinterfragt. Auf diese Weise 
wird die Prozessbeschreibung überprüft. Ein Walk Through wird mit etwa zwei bis vier 
Prozessbeteiligten durchgeführt, die verschiedene Benutzergruppen vertreten. 

Die „Autoren“ der Prozessbeschreibung (beispielsweise Prozess-Manager), soll- 
ten sich dabei im Hintergrund halten, damit Kritik offen formuliert werden kann. Alle 
Kritikpunkte und Anregungen werden gesammelt, dokumentiert und anschließend mit 
den Prozess-Beteiligten ausgewertet. Diese Auswertung führt zu einer Überarbeitung des 
Prozesses. Das folgende Bild gibt einen Eindruck von einem Walk-Through-Workshop. 
Es zeigt auch, dass dies bei der Verwendung von Swim-Lane-Methoden im Rahmen der 
Modellierung zu einer aufwendigen Angelegenheit werden kann. Mit Swim Lanes kön- 
nen Prozessmodelle nicht hierarchisch beschrieben werden, sodass komplexe Modelle 
sehr viel Platz benötigen. 

Die schrittweise Analyse eines Prozesses kann durch entsprechende Werkzeuge unter- 
stützt werden. Das verwendete Werkzeug zeigt das Prozessmodell am Bildschirm, und 
der aktuelle Prozessschritt wird farblich hervorgehoben. 


5.2.1.3 Rollenspiele 

Die nächste Steigerung für eine erlebbare Überprüfung von Prozessmodellen sind 
Rollenspiele. Diese sind insbesondere dann gut einsetzbar, wenn kommunikations- 
orientierte Modellierungssprachen verwendet werden. Die Handelnden sind dann bereits 
identifiziert und diese Rollen werden dann geeigneten Personen zugeordnet. Von einem 
Spielleiter werden Prozessanstöße ausgelöst und die notwendigen Eingaben zur Ver- 
fügung gestellt. Diese Prozessinstanzen werden dann von den einzelnen Rolleninhabern 
gemäß den Prozessbeschreibungen abgearbeitet. Diese „Prozessabläufe“ werden von 
anderen Betroffenen beobachtet und die identifizierten Auffälligkeiten werden notiert. 
Nach der Abarbeitung von einigen Prozessinstanzen werden die Befunde bewertet und 
notwendige Anpassungen identifiziert. 

Die Ausführung von Rollenspielen kann durch geeignete IT-Werkzeuge unterstützt 
werden. Die Rolleninhaber eines Rollenspiels erhalten ihre Rollenbeschreibung nicht 
auf Papier, sie werden mittels Software, die insbesondere die Ablauflogik implemen- 
tiert, durch den Prozess geführt. Diese Software wird dabei unmittelbar und automatisch 
aus dem Prozessmodell generiert. Voraussetzung dafür ist dass die Semantik der ver- 
wendeten Prozessmodellierungssprache eindeutig definiert ist. Dies ist beispielsweise 
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für BPMN bedingt und für EPKs gar nicht der Fall, jedoch bei S-BPM dank einer ein- 
deutigen, formalen Semantik erfüllt. 

Das folgende Bild (siehe Abb. 5.17) zeigt, wie eine IT-gestützte Validierung aussehen 
kann. Der Vorteil eines IT-gestütztes Rollenspiels ist, dass die Vorbereitungszeit sehr 
gering ist und das Prozesserleben schon sehr nahe an der späteren Prozessausführung liegt. 


5.2.2 Optimierung 


Nach der Prüfung der Effektivität (liefern die Prozesse überhaupt das gewünschte 
Ergebnis?), muss überprüft werden, ob das Ergebnis mit dem geringsten möglichen Ein- 
satz von Ressourcen zustande kommt. Eine Optimierung durch manuelle Prüfung, Walk 
Throughs oder Rollenspiele ist nur sehr eingeschränkt möglich. Die hierbei gewonnenen 
Erkenntnisse liefern nur eine Annäherung für die Ermittlung des Ressourcenbedarfs bei 
einer angenommenen Anzahl von Prozessdurchläufen. Eine systematische Ermittlung 
des Ressourcen- und Zeitbedarfs ist nur durch eine Simulation möglich. Voraussetzung 
für eine Simulation ist allerdings, dass das Prozessmodell ausführbar ist. 

Bei der Simulation von Geschäftsprozessen werden die von einem Prozess verarbeiteten 
Geschäftsereignisse zufällig gemäß einer angenommenen Wahrscheinlichkeitsverteilung 
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Abb. 5.17 Szenerie für ein IT-gestütztes Rollenspiel 
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erzeugt. In der Regel ist dies die Exponentialverteilung mit einem vermuteten oder durch 
Beobachtung ermittelten Erwartungswert. Den einzelnen Arbeitsschritten werden die 
entsprechenden Ressourcen mit der benötigten Arbeitszeit zugeordnet. Die benötigte 
Arbeitszeit folgt in der Regel einer Normalverteilung mit aus Beobachtung ermittelten 
Erwartungswerten und Standardabweichungen. 

Im Rahmen der Simulationsläufe werden Informationen über die Ablauffähigkeit von 
Prozessen, über Prozess-Schwachstellen und Ressourcenengpässe geliefert. Auf Basis 
der simulierten Prozesskennzahlen können bereits im Vorfeld kostenintensiver Prozess- 
änderungen innerhalb eines Unternehmens verschiedene Alternativen bewertet und ein 
realitätsgetreues Benchmarking durchgeführt werden. 

Moderne Werkzeuge und Simulationsmethoden ermöglichen die Analyse und Opti- 
mierung der Prozesse bezüglich der Kosten, der Durchlaufzeiten, der Auslastung 
oder der Engpässe. Zusätzlich bildet die Simulation der Geschäftsprozesse eine Aus- 
gangsbasis zur Einführung der Prozesskostenrechnung anstelle der relativ ungenauen 
Zuschlagskalkulation. Die Gewinne bzw. Verluste der einzelnen Bereiche werden damit 
frühzeitig transparent. 

Die Durchführung einer Simulationsuntersuchung setzt wie bereits erwähnt eine 
präzise Beschreibung des betrachteten Prozesses voraus. Dies bedeutet, dass zur Defi- 
nition des Prozessablaufes eine formale Methode verwendet wird. Zusätzlich sind mög- 
lichst genaue Kenntnisse über die Wahrscheinlichkeitsverteilungen, deren Parameter und 
der untersuchten Kennzahlen notwendig. In der Praxis werden Simulationen wegen des 
damit verbundenen hohen Aufwandes nicht häufig eingesetzt, obwohl die gewonnenen 
Erkenntnisse überzeugend sein können. 
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Umsetzung 


Die bisherigen Ausführungen haben mit der Spezifikation effektiver und effizienter 
Prozesse die Grundlagen gelegt für deren Implementierung. Im Anschluss an diese 
vorbereitenden Aktivitäten befassen wir uns in der Folge mit der Umsetzung der 
Prozessspezifikation in einer Ausführungsumgebung und der Abwicklung von Prozess- 
instanzen im Echtbetrieb. Die Umsetzung einer Prozessbeschreibung in einen ausführ- 
baren Prozess umfasst die Aktivitätsbündel der organisatorischen Implementierung, der 
IT-Implementierung und des Betriebs mit dem Monitoring. Abb. 6.1 zeigt die Einordung 
dieser Aktivitäten in das Prozessmanagementmodell. 

In den folgenden Abschnitten werden, ausgehend von Überlegungen zur Dokumen- 
tation der erarbeiteten Prozessspezifikation, ausgewählte Methoden für die Aktivitäts- 
bündel der organisatorischen und IT-Implementierung sowie für den Betrieb und das 
Monitoring von Prozessen vorgestellt. 

Die Aktivitäten des Prozessmanagementmodells bieten den konzeptionellen Rahmen 
für die Umsetzung des Geschäftsprozessmanagements in ein Handlungssystem. Wie 
bereits in den vorangestellten Kapiteln diskutiert, stellen die Phasen zwar ein gewisses 
Ordnungskriterium dar, können aber grundsätzlich in beliebiger Reihenfolge durchlaufen 
werden. Jede der Phasen beinhaltet dabei ein Bündel an Aktivitäten, die typischerweise 
in ihr angewendet werden. Jeder Geschäftsprozess befindet sich in einem bestimmten 
Augenblick in einer bestimmten Phase — oder in anderen Worten, in einem bestimmten 
Zustand: er ist modelliert, er ist in Kraft gesetzt, er wird ausgeführt, er wird ana- 
lysiert. Das Lebenszyklusmodell definiert damit einen Phasen- oder Zustandsraum für 
Geschäftsprozesse. 
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Abb. 6.1 Einordnung Umsetzung 
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6.1 Prozessdokumentation 


Da die Geschäftsprozesse eines Unternehmens definieren, wie Produkte und Dienst- 
leistungen entwickelt, hergestellt und geliefert werden, ist es zweckmäßig eine 
Prozessdokumentation zu erstellen. Diese sollte naturgemäß allen Mitarbeitern zent- 
ral zur Verfügung gestellt werden. Die Dokumentation muss spätestens zu Beginn der 
Umsetzung (Implementierung) vorliegen. Die Geschäftsprozessdokumentation ist das 
Ergebnis der Aktivitätsbündel während der Vorbereitung. 

Heutzutage bietet sich dazu die Form digitaler Dokumente an. Die Bereitstellung 
erfolgt dabei idealerweise über ein üblicherweise vorhandenes Intranet; damit kann auch 
in groben Zügen eine einfache Zugriffskontrolle gestaltet werden. Die Dokumente selbst 
können beispielsweise nicht veränderbare PDF-Dateien (eventuell auch digital signiert), 
oder HTML-Dateien, die über einen Browser betrachtet werden können, sein. 

Für kleinere Organisationen und Unternehmen reicht es zumeist aus, wenn für 
die Erstellung und Wartung der Prozessdokumentation die üblicherweise verwendete 
Bürosoftware genutzt wird. Für umfangreichere Sammlungen erscheint die Nutzung 
spezifischer Software, sogenannter Business Prozess Management Systeme (BPMS), 
überlegenswert. Jedenfalls muss die gewählte Form die Menschen, die damit arbeiten, 
und die darauf aufbauenden Managementsysteme bestmöglich unterstützen. Auch soll- 
ten die Dokumente eine eindeutige Bezeichnung, eine Versionsnummer und ein Datum 
beinhalten. Soll eine Textverarbeitung benutzt werden, empfiehlt sich eine Formatvor- 
lage, um ein einheitliches Erscheinungsbild und ebensolche Strukturen vorzugeben. Des 
Weiteren empfiehlt sich eine Liste mit allen Dokumenten inklusive Historie, um einen 
allgemeinen Überblick zur Verfügung zu stellen. 

Verantwortlich für die Aktualität und Vollständigkeit einer Prozessdokumentation 
ist der Prozesseigner bzw. Prozesskoordinator. Das Prozess-Office gibt vor, was 
eine Prozessdokumentation beinhalten soll und stellt entsprechende Vorlagen und 
Erklärungen bereit. Falls ein dediziertes IT-System (BPMS) genutzt werden soll, kann 
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die Schulung aller Mitarbeiter — abhängig davon, welche Rolle sie einnehmen - ein- 
dringlich angeraten werden. Im Sinne eines geplanten Veränderungsprozesses (Change 
Management), sollten die Mitarbeiter in angemessener Form auch in den Auswahl- oder 
Entwicklungsprozess eingebunden werden. 

Folgende Inhalte einer Prozessdokumentation haben sich grosso modo bewährt; 
selbstverständlich sind nicht immer alle Punkte für jeden Geschäftsprozess relevant und 
können bei Bedarf auch weitere Punkte ergänzt werden: 


e Ziel des Prozesses — ein kurzer beschreibender Text, in dem der Bezug des Prozesses 
zu übergeordneten Unternehmenszielen erläutert wird (Strategiebeitrag). 

e Auslöser des Prozesses — Angabe, durch welches Ereignis eine Prozessinstanz 
gestartet wird und wer dieses Ereignis erzeugen kann. 

e Input - Auflistung und Beschreibung der Informationen, Dokumente und auch phy- 
sikalischen Artefakte, die als Input benötigt werden und von wem sie bereitgestellt 
werden. 

e Output — Auflistung und Beschreibung der Informationen, Dokumente und physika- 
lischen Artefakte, die vom Prozess erzeugt werden; eventuell auch Qualitätskriterien 
pro Kunde. 

e Gültigkeitsbereich und organisatorische Rahmenbedingungen — gegebenenfalls 
Abgrenzung zu anderen Geschäftsprozessen, oder organisatorische Einschränkung 
(z. B. nur gültig für den Geschäftsbereich Großkunden). 

e Definition der Begriffe und Abkürzungen - im Dokument verwendete 
Abkürzungen; Tipp: wenn man diese auch gleich in einem unternehmensweiten Ver- 
zeichnis konsolidiert sammelt, erhält man ein Glossar der wichtigsten Begriffe in 
einem Unternehmen, sowie einheitliche Definitionen in allen Prozessdokumentationen. 

e Übersichtsbeschreibung des Prozessmodells — textuelle Darstellung der Handeln- 
den/Rollen und der Prozessschritte. 

e Prozessmodell — Ein Prozessmodell (visuelle Darstellung), erstellt in einer verein- 
barten Modellierungssprache; für die Erstellung der Prozessmodelle sollte es einheit- 
liche Regelungen geben, um einen Wildwuchs zu vermeiden (z. B. bezüglich Farben 
und Beschriftung von Notationselementen). 

e Technische Rahmenbedingungen — Auflistung und Beschreibung technischer Hilfs- 
mittel, die im Prozess benötigt werden. Darstellung der informationstechnischen 
Unterstützung bzw. Abhängigkeiten, z. B. der Verweis auf bestimmte Module eines 
ERP-Systems. 

e Feedback Mechanismen - Darstellung, wie Prozessbeteiligte Probleme bei der Aus- 
führung (z.B. falsch oder nicht ausreichend modellierte Logik) artikulieren oder 
Verbesserungsvorschläge einbringen können. Dies sollte eine im Geschäftsprozess- 
management implementierte Standardprozedur sein. 

e Ausnahmen - eventuelle Ausnahmen vom Prozessmodell, d. h. Aktivitäten, die nicht 
im Prozessmodell berücksichtigt werden, da entsprechende Fälle nur selten vorkommen. 
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e Schnittstellen mit anderen Prozessen — eine Darstellung, in welchen anderen 
Geschäftsprozessen der Output eines Prozesses benötigt wird (definiert damit den 
Prozesskunden bzw. dessen Erwartung). 

e Kennzahlen (PPI) - Liste, Definition und Erklärung der vorgesehenen Prozesskenn- 
zahlen. 

e Leistungsmessungen — Darstellung, wie und wann die Kennzahlen zu messen und zu 
berechnen sind. Verweis auf eventuell verfügbare andere Dokumente. 

e Berichtswesen — Darstellung, in welcher Form und wann die Prozesskennzahlen an 
wen zu berichten sind; Verweis auf eventuell verfügbare andere Dokumente. 

e Eskalationen — Definition von Prozeduren, die anlaufen sollen, sobald der Toleranz- 
bereich von Kennzahlen verletzt wird. 

e Audits und Compliance — Verweis auf entsprechende Richtlinien. Falls einzelne 
Aktivitäten in einem Geschäftsprozess aus Gründen der Compliance aufgenommen 
wurden, sollte dies dokumentiert werden, damit diese nicht im Rahmen einer 
Effizienzverbesserung eliminiert werden. Es empfiehlt sich, solche Aktivitäten in einer 
visualisierten Darstellung farblich zu markieren. Ferner hat sich in der Praxis als hilf- 
reich erwiesen, (tabellarisch) zu dokumentieren, in welchen Geschäftsprozessen die 
Einhaltung bestimmter Normen und Gesetze notwendig ist. Ähnliche Überlegungen 
gelten für externe (z. B. Qualitätsnormen) oder interne Audits (z. B. Risikoanalysen). 


6.2 Verknüpfung von Elementen der 
Unternehmensarchitektur 


6.2.1 Überblick 


Wie in Kap. 1 und 2 angesprochen, sind Geschäftsprozesse Teil der Unternehmensarchi- 
tektur. Unternehmensarchitekturen gehen auf die internen Aspekte und Strukturen eines 
Unternehmens ein. Sie sind im Wesentlichen Modelle der Interna eines Unternehmens 
und umfassen nicht nur organisatorische, sondern auch technische Aspekte, insbesondere 
die eingesetzte IT. Bei der Umsetzung der Prozessmodelle gilt es nun deren Bezug zu 
den vorhandenen Ressourcen herzustellen. Abb. 6.2 zeigt die einzelnen Stufen vom 
Prozessmodell zur ausführenden Prozessinstanz. 

In einem Prozessmodell werden die Handelnden, die Handlungen, deren Reihen- 
folgen und die Objekte, auf denen die Handlungen ausgeführt werden, beschrieben. 
Handlungen (Aktionen, Aktivitäten) können von Menschen, Softwaresystemen, physika- 
lischen Systemen oder einer Kombination aus diesen Grundtypen von Handelnden aus- 
geführt werden. Wir bezeichnen sie als Aufgabenträger. So kann ein Software-System 
die Aktion „Berechnung des Steuersatzes“ automatisch erledigen, während ein Mensch 
in Kombination mit einem Programm die Aktivität „Erfassen der Bestellung“ ausführt. 
Der Mensch tippt dabei die Bestelldaten über eine Bildschirmmaske ein. Die Software 
prüft die eingegebenen Daten auf Plausibilität und speichert sie ab. 
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Abb. 6.2 Vom Prozessmodell zur Prozessausführung 


Tätigkeiten können aber auch ausschließlich manuell ausgeführt werden, etwa wenn 
ein Lagerarbeiter einen Kommissionierungsauftrag auf Papier bekommt, diesen aus- 
führt, auf dem Auftrag als ausgeführt kennzeichnet, und an den Lagermeister zurückgibt. 
Bei der Erstellung eines Prozessmodells ist oft noch nicht bekannt, welche Typen von 
Handelnden welche Aktionen ausführen. Deshalb kann es sinnvoll sein, zu Beginn einer 
Prozessbeschreibung davon zu abstrahieren, in dem man abstrakte Handelnde einführt. 
Eine Modellierungssprache sollte erlauben, solche Abstraktionen zu verwenden. Dies 
bedeutet, es muss bei der Definition der Prozesslogik noch keine Aussage gemacht wer- 
den, durch welchen Typ ein Akteur realisiert wird. In S-BPM repräsentieren die Subjekte 
abstrakte Handelnde. In BPMN können Pools oder Swim Lanes als abstrakte Handelnde 
interpretiert werden, während man in EPKs dafür Rollen verwenden kann. 

In der Beschreibung der Ablauflogik eines Prozesses werden auch die einzelnen 
Aktivitäten noch unabhängig von ihrer Realisierung beschrieben. Beispielsweise wird 
bei einer Aktion „Erstellen eines Kommissionierungsauftrags“ nicht festgelegt, ob 
hier der Bearbeiter ein Papierformular oder eine Bildschirmmaske ausfüllt, oder ob 
ein Software-System diesen vollautomatisch erzeugt. Bei Aktionen wird also nicht 
beschrieben, mit welchen Mitteln etwas geschieht, sondern nur was geschieht. 

Dies steht natürlich in Zusammenhang mit dem Implementierungstyp für den Han- 
delnden als Aufgabenträgertyp. Sobald festgelegt wird, welche Typen von Handeln- 
den den einzelnen Aktionen zugewiesen werden, ist auch die Art der Realisierung 
einer Aktivität definiert. Darüber hinaus ist zu definieren, auf welchem logischen oder 
physischen Objekt eine Aktion ausgeführt wird. Logische Objekte sind Datenstrukturen, 
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deren Daten durch die Aktivitäten manipuliert werden. Papierformulare stellen eine 
Mischung zwischen logischen und physischen Objekten dar, während ein Werkstück, 
auf dem die Aktion „Entgraten“ stattfindet, ein rein physisches Objekt ist. Es besteht 
also ein enger Zusammenhang zwischen dem Aufgabenträgertyp, den Aktionen und den 
zugehörigen Objekten, auf oder mit denen die Akteure Handlungen ausführen. 

Ein Prozessmodell kann in verschiedenen Bereichen einer Organisation zum Einsatz 
kommen. Die Prozesslogik wird dann in den jeweiligen Bereichen unverändert über- 
nommen. Es kann allerdings nötig sein, die einzelnen Handelnden und Handlungen 
unterschiedlich zu implementieren. So können in einer Umgebung bestimmte Hand- 
lungen von Menschen und in einer anderen die gleiche Aktivität von Software-Systemen 
ausgeführt werden. Wir bezeichnen solche verschiedenen Verwendungsumgebungen für 
ein Prozessmodell im Folgenden als Kontext. Für ein Prozessmodell kann es also vari- 
ierende Kontexte geben, in denen die Realisierungstypen für Akteure und Aktionen von- 
einander abweichen können. 

In BPMN kann der Modellierer für jeden Task separat festlegen, ob es sich um einen 
sogenannten Human Task, Service Task oder User Task handelt. User Tasks führen Men- 
schen zusammen mit Software aus, wie z. B. das Ausfüllen eines Kommissionierungs- 
auftrags am Bildschirm. Dies bedeutet, dass die Beschreibung des Implementierungstyps 
in BPMN einen Teil der Prozesslogik darstellt. Da in BPMN Pools und Swim Lanes als 
Handelnde interpretiert werden können, muss darauf geachtet werden, dass keine Wider- 
sprüche mit dem Implementierungstyp von Tasks innerhalb z. B. eines Pool entstehen. 
Legt der Designer beispielsweise fest, dass ein Pool nur durch Menschen ausgeführt 
wird, kann dieser Pool keine Service oder User Tasks enthalten. Da in BPMN die Defini- 
tion des Implementierungstyps Bestandteil des Ablaufmodells ist, muss unter Umständen 
für jeden Kontext ein eigenes Prozessmodell erstellt werden. 

In S-BPM werden Handelnde nicht einzelnen Aktivitäten zugeordnet, sondern der Typ 
des Handelnden einem gesamten Subjekt. Diese Zuordnung ist in S-BPM nicht Teil der 
Prozesslogik, sondern erfolgt je Prozess in einer separaten zweispaltigen Tabelle. In der 
linken Spalte findet sich der Subjektname und in der rechten der Implementierungstyp. 
Gibt es für ein Ablaufmodell mehrere Kontexte, so wird für jeden von ihnen eine eigene 
Zuordnungstabelle erstellt. 

Die Zuordnung des Implementierungstyps bildet den Übergang zwischen der Prozess- 
logik und deren Implementierung. Anschließend muss noch definiert werden, welche 
Personen, Softwaresysteme und physikalische Systeme die Handelnden repräsentie- 
ren, und wie die einzelnen Aktionen konkret realisiert werden. In den folgenden Unter- 
kapiteln werden diese Aspekte detailliert beschrieben. 


6.2.2 Menschen und Organisation 
Für jeden Kontext gilt es für alle Handlungen, an denen Menschen beteiligt sind, die 


jeweiligen Aufgaben- oder Handlungsträger, und damit konkret die ausführenden Perso- 
nen oder Organisationseinheiten festzulegen. 
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In Unternehmen und Verwaltungen gibt es Personen mit unterschiedlicher Aus- 
bildung, Qualifikationen, Vorlieben und Interessen. Es gibt Kaufleute, Entwickler, Hand- 
werker usw., welche die anfallenden Tätigkeiten erledigen. Organisationen kann man 
daher auch als strukturierte Ressourcenpools bezeichnen. Je nach Art und Umfang der 
Aufgaben bildet die Organisation Einheiten, in denen die jeweiligen Spezialisten dafür 
zusammengefasst werden. So existieren Abteilungen für den Einkauf mit Beschaffungs- 
experten, oder Entwicklungsabteilungen, die aus mehreren Entwicklungsingenieuren und 
sonstigen Fachleuten gebildet werden. Der Bezug zwischen den Personen und Organisa- 
tionen in der Aufbauorganisation zu den abstrakten Handelnden in den Prozessen kann 
statisch oder dynamisch hergestellt werden. 


Statische Zuordnung 

Im einfachsten Fall gibt die bereits erwähnte zweispaltige Tabelle Aufschluss darüber, 
welchem im Prozess definierten Akteur (Spalte 1) welche Personen oder Organisationen 
bzw. Organisationseinheiten zugeordnet sind (Spalte 2). Die zweite Spalte kann auch 
eine Organisation bzw. Organisationseinheit enthalten. Dann sind ihre Mitglieder dem 
abstrakten Handelnden zugeordnet. Damit wird erreicht, dass bei Krankheit oder Urlaub 
eine beliebige Person aus der Organisation die im Prozess anfallenden Aufgaben über- 
nehmen kann. Außerdem lässt sich so auch die Arbeitslast verteilen, wenn Handlungen 
aus mehreren Prozessabläufen (Prozessinstanzen) abgearbeitet werden müssen. 

Bei BPMN können Pools, Swim Lanes und einzelne Aktionen separat einem Aus- 
führenden zugeordnet werden. Hier ist darauf zu achten, dass bei der Verwendung aller 
Zuordnungsmöglichkeiten keine Inkonsistenzen entstehen. Wenn ein Software-System 
eine Swim Lane als Handelnder ausführt und in dieser Swim Lane eine Human Task 
liegt, so ist nicht klar, was dies bedeutet. Für das BPMN-basierte Werkzeug von Bonita- 
soft [1] wurden deshalb Actors eingeführt. Sie sind Platzhalter für Aufgabenträger, denen 
dann, ähnlich den Subjekten in der Subjektorientierung, konkret Handelnde zugeordnet 
werden. 

Bei S-BPM wird jeweils ein komplettes Subjekt in die Organisation eingebettet, d. h. 
die Zuordnung gilt dann für alle Aktionen in einem Subjekt. 


Dynamische Zuordnung 
In vielen Prozessen kann die Zuordnung der Handelnden aus dem Prozess zu Personen 
und Organisationen nicht statisch festgelegt werden. So kann bei einem Geschäftsreise- 
antrag der Bearbeiter davon abhängen, ob es sich um eine Inlands- oder Auslandsreise 
handelt. Während die Ablauflogik in beiden Fällen gleich sein kann, unterscheiden 
sich möglicherweise die ausführenden Personen, beispielsweise, weil ein Mitarbeiter 
besondere Expertise für internationale Reisen mit Visaangelegenheiten besitzt. 

In solchen Fällen ist es sinnvoll, die handelnden Personen oder Organisations- 
einheiten erst beim Ablauf der Prozesslogik beispielsweise in Abhängigkeit von Daten- 
werten in Geschäftsobjekten (hier im Reiseantrag) zu ermitteln und zuzuordnen. 
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Für eine flexible, dynamische Zuordnung der Bearbeiter sind in der Regel Tabellen 
nicht mehr ausreichend, sondern es sind programmiersprachliche Konstrukte notwendig. 
Lavall etal. [2] zeigen, wie eine solche Sprache verwendet werden kann, um subjekt- 
orientierte Prozessmodelle in Organisationen einzubetten. Da in BPMN die Zuordnung 
der Bearbeiter über Pools, Lanes und Tasks möglich ist, gestaltet sich die Beschreibung 
der Zuordnung dort als sehr komplex. Verschiedene BPMN-basierte Werkzeuge wie 
Bonita [3] oder Activiti [4] integrieren Prozesse in die Organisation durch Programmie- 
rung in Java bzw. XML. 


6.2.3 Physikalische Infrastruktur 


Insbesondere in Fertigungsprozessen sind physikalische Systeme als Handelnde 
beteiligt. So können einer Maschine Rohteile über ein Transportsystem zugeführt wer- 
den, die Maschine bearbeitet die Rohteile und die bearbeiteten Teile werden zum nächs- 
ten Bearbeitungsschritt weiter transportiert. Wird eine solche Maschine als Subjekt oder 
Pool betrachtet, so werden die zugeführten Teile als zu empfangende und die abtrans- 
portierten Teile als zu sendende Nachrichten modelliert. Der Modellierer stellt den 
Bearbeitungsschritt als einzelnen Task in einem Subjekt oder Pool dar. 


6.2.4 IT-Infrastruktur 


Digitalisierung in der Wirtschaft bedeutet, Prozesse mit möglichst umfassender Unter- 
stützung durch Software-Systeme umzusetzen. In entsprechenden Szenarien erledigen 
weitgehend Computer oder Maschinen die Tätigkeiten, menschliche Eingriffe werden 
soweit möglich und sinnvoll reduziert. Wesentliche Aspekte dabei sind: 


e Die Steuerung des Prozessablaufs: 
Die im Prozessablauf beschriebenen Handlungsfolgen werden automatisch durch 
Computerprogramme gesteuert. 

e Die Ausführung von Handlungen: 
Handlungen auf Datenobjekten können oft vollautomatisch durch entsprechende 
Computerprogramme ausgeführt werden. 


Software-Systeme sind das Mittel zur Zusammenführung der verschiedenen Handlungs- 
typen. So bindet beispielsweise eine Process Engine bei der Steuerung des Prozess- 
ablaufs die menschlichen und maschinellen Bearbeiter zur Laufzeit situationsgerecht in 
die Abarbeitung von Instanzen ein. 

In den folgenden Ausführungen wird auf die Steuerung des Prozessablaufs und die 
Manipulation der zugehörigen Geschäftsobjekte durch Informationstechnologie ein- 
gegangen, jedoch noch ohne die Einbindung von Menschen oder physikalischen Systemen 
als Aufgabenträger näher zu betrachten. Diese ist Gegenstand von Abschn. 6.2.5. 
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Ablauf 

Die Prozesslogik entspricht der Ablauflogik eines Computerprogramms. Die automatische 
vollständige Ausführung der Prozesslogik durch ein Computerprogramm ist nur bei stark 
strukturierten Prozessen möglich. Alle denkbaren Ablaufmöglichkeiten müssen abgedeckt 
sein. Es sind keine menschlichen Eingriffe vorgesehen. Um zu vermeiden, dass die 
beschriebene Prozesslogik von der Ausführungslogik des Computerprogramms abweicht, 
ist es hilfreich, wenn das Computerprogramm automatisch aus der Beschreibung der 
Prozesslogik abgeleitet werden kann. Dafür müssen folgende Voraussetzungen vorliegen: 


e Die Syntax und Semantik der Sprache, in der die Prozesslogik beschrieben ist, muss 
präzise definiert sein. 

e Die Beschreibung des Prozessablaufs muss in elektronischer Form vorliegen. 

e Es muss ein Umsetzungsprogramm vorliegen, das die elektronische Form der 
Beschreibung der Prozesslogik liest und daraus, basierend auf der präzisen Seman- 
tik der Prozessbeschreibungssprache, ein Computerprogramm in einer geeigneten 
Programmiersprache erzeugt. 


Die Bedeutung bereits heute weit verbreiteter verteilter Systeme nimmt mit der Ent- 
wicklung von Cloud und Edge Computing weiter zu. Dies kann bedeuten, dass auch 
Teile eines voll automatisierten Prozesses in einem verteilten System auf verschiedenen 
Rechnerknoten zur Ausführung kommen sollen. Da diese auf unterschiedlichen Techno- 
logien basieren können, müssen unter Umständen entsprechende Varianten für die auto- 
matische Umsetzung einer Ablaufbeschreibung in ein Computerprogramm verfügbar sein. 

So können einzelne Subjekte einer S-BPM Beschreibung eines Prozesses auf unter- 
schiedlichen Rechnerknoten eines verteilten Systems ablaufen. Dies kann bedeuten, dass 
der Programmcode für jedes Subjekt separat generiert werden muss. Vermeiden lässt 
sich dies, wenn der generierte Zielcode auf möglichst allen Knotentypen des verteilten 
Systems zur Verfügung steht, und dieses Zielsystem über ein Framework verfügt, durch 
das die auf verschiedenen Knoten laufenden Programmteile zusammenarbeiten können. 
Die Software-Komponenten synchronisieren ihre Zusammenarbeit in der Regel durch 
den Austausch von Nachrichten. Eine Programmiersprache, die dies ermöglicht, ist z. B. 
Java mit dem Framework AKKA, das den Nachrichtenaustausch über Rechnergrenzen 
hinweg erlaubt, auch ausgehend von S-BPM-Modellen [5]. 

In BPMN können einzelne Pools prinzipiell auf verschiedenen Rechnerknoten aus- 
geführt werden. Dies setzt voraus, dass eine Kommunikation zwischen den Pools über 
Rechnergrenzen hinweg möglich ist. Eine Recherche nach Möglichkeiten einer ent- 
sprechenden Codegenerierung für BPMN-Modelle im Frühjahr 2018 brachte keine 
Ergebnisse. 


Aktivitäten und Daten 
Bei vollständig digitalisierten Prozessen führen Computersysteme auch die im Prozess- 
ablauf enthaltenen Aktivitäten aus. Dies kann mittels Funktionen oder Services geschehen, 
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die bereits in existierenden Anwendungsprogrammen verfügbar sind, und nur an den 
geeigneten Stellen in das Programm, das den Prozessablauf realisiert, eingefügt bzw. auf- 
gerufen werden. 

Für die Integration neu entwickelter Software für Aktivitäten kommen häufig 
Technologien zum Einsatz wie Web Services, REST-Schnittstellen oder einfache APls. 
Datenbankzugriffe zur direkten Manipulation von Daten können abhängig von den 
Schnittstellen der verwendeten Datenbanksysteme analog eingebunden werden. 

Bei der Verwendung von S-BPM gehören Daten zu einem Subjekt. Es ist nicht 
erlaubt, dass mehrere Subjekte auf gemeinsame Daten zugreifen. Möchten mehrere Sub- 
jekte die gleichen Daten z. B. in einer Datenbank nutzen, so muss diese in ein Subjekt 
‚eingepackt‘ werden. Dieses Subjekt nimmt dann die entsprechenden Anfragen von den 
anderen Subjekten entgegen, führt die gewünschte Aktion aus und schickt das Ergebnis 
an das anfordernde Subjekt zurück. 

Aktivitäten zusammen mit ihren Daten werden in der Software-Technologie als Klas- 
sen bezeichnet. Mehrere solcher Klassen können zu Services zusammengeschlossen 
werden. In der IT wird dann von einer Service-orientierten Architektur gesprochen. 
Die Services werden entsprechend der Ablauflogik des Prozesses aufgerufen. Tasks in 
BPMN können durch Services realisiert werden. Analog dazu können die Funktionen 
innerhalb eines Subjekts implementiert werden. 

Ein aktuelles Konzept zur Strukturierung von Software-Systemen sind Microservices 
[6]. Microservices beschreiben eine Architektur, bei der einzelne kleine fachliche Soft- 
ware-Bausteine unabhängig voneinander und, bei Bedarf, auf verschiedenen technischen 
Plattformen programmiert, getestet, abgenommen und bereitgestellt werden. Durch ihr 
Zusammenspiel über von der Programmiersprache unabhängige Schnittstellen lässt 
sich komplexe Anwendungssoftware realisieren. Dabei kommunizieren Microservices 
meist durch den Austausch asynchroner Nachrichten. Dies entspricht auch dem Kon- 
zept des Reactive Programming [7], dessen wesentliche Eigenschaft die Kopplung von 
Programmbausteinen durch asynchrone Nachrichten ist. 

In BPMN können Pools als Microservices implementiert werden, falls alle Tasks in 
einem Pool vom gleichen Aufgabenträger ausgeführt werden. 

Bei S-BPM sind Subjekte immer einem Aufgabenträger zugeordnet und kommu- 
nizieren über den asynchronen Austausch von Nachrichten. Deshalb entspricht ein 
subjektorientiert beschriebener Prozess mit Blick auf die IT-Architektur einer Micro- 
service-orientierten Struktur, die den Anforderungen des Reactive Programming genügt. 


6.2.5 Kombinationen von Aufgabenträgern 


Tasks werden häufig nicht von einem einzigen Aufgabenträgertyp ausgeführt. Mit der 
zunehmenden Digitalisierung werden beispielsweise die Aufgaben, die ausschließ- 
lich Menschen ausführen, immer seltener. So erhält heute ein Lagerarbeiter seine 
Kommissionierungsaufträge häufig über ein Tablet, das mit einem IT-System verbunden 
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ist. Nachdem er die Waren zusammengestellt hat, bestätigt er dies auch auf dem Tab- 
let. Damit ist die Kommissionierungsaufgabe abgeschlossen. Das IT-System aktualisiert 
die Daten und stößt die Folgeaufgabe wie z. B. die Vorbereitung der Versanddokumente 
automatisch an. Die Kommissionierungsaufgabe wird also durch Mensch und IT als 
Typen von Aufgabenträgern ausgeführt, eine Kombination, die man in Geschäfts- 
prozessen sehr häufig findet. Die IT übernimmt dabei zumindest die Steuerung der 
Prozesslogik und die Verwaltung der Daten, während Menschen Eingaben tätigen oder 
Maschinen bedienen. 

Von Kleinrechnern mit entsprechender Software gesteuerte Maschinen lösen 
zunehmend Maschinen als rein mechanische Aufgabenträger ab. Diese eingebetteten 
Systeme (Embedded Systems) steuern die Mechanik und wickeln die Kommunikation 
mit anderen Maschinen oder übergeordneten Geschäftsanwendungen ab. Die Kommu- 
nikation mit anderen intelligenten Maschinen wird als horizontale Kommunikation und 
mit Geschäftsanwendungen als vertikale Kommunikation bezeichnet. Letztere verknüpft 
Produktionssysteme mit Geschäftsprozessen und ist ein wesentlicher Bestandteil der 
Industrie 4.0 Initiative. 

In den folgenden Abschnitten wird nun detaillierter beschrieben wie die ver- 
schiedenen Aufgabenträger in die Implementierung der Prozessablauflogik integriert 
werden. 


Kombination Mensch-IT 

Die Kombination von Mensch und IT bei der Ausführung von Geschäftsprozessen ist 
der Kern deren Digitalisierung. Die IT übernimmt dabei zumindest die Steuerung der 
Prozesslogik, d. h. sie veranlasst entsprechend der Prozesslogik, dass die vorgesehenen 
Aufgaben von den jeweiligen Aufgabenträgern erledigt werden. Zusätzlich können 
Aufgaben von der IT direkt als Aufgabenträger ausgeführt werden, ohne dass Men- 
schen eingebunden werden müssen. Kann eine Aufgabe nur durch menschliche Unter- 
stützung erledigt werden, fordert die für die Ablauflogik zuständige Software über eine 
entsprechende Benutzungsschnittstelle den zuständigen menschlichen Aufgabenträger 
dazu auf. Dies kann zur Eingabe von Daten sein, aber auch zur Rückmeldung, dass der 
Benutzer eine manuelle Aktion ausgeführt hat. 

IT-Systeme als Steuerungssoftware und als Handlungsträger für Aktivitäten über- 
nehmen in der Regel auch die Speicherung der während einer Prozessausführung 
anfallenden Daten, sowohl Inhalte von Geschäftsobjekten, als auch Metadaten wie Zeit- 
stempel für Beginn und Ende von Instanzen und Ausführungsschritten. 

Eine umfassende Plattform zur Implementierung von Geschäftsprozessen, die Men- 
schen und IT-Lösungen ausführen, wird als Workflow-Management-System bezeichnet. 
Die Workflow Management Coalition (WfMC) hat dafür ein Referenzmodell entwickelt. 
Abb. 6.3 zeigt die darin vorgesehenen Komponenten und Schnittstellen [8]. 
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Abb. 6.3 Referenzmodell für Workflow-Management-Systeme (WFMS) 
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Die Schnittstellen zwischen den einzelnen Komponenten sind wie folgt definiert: 


e Prozessdefinition (Schnittstelle 1) 
Schnittstelle zwischen Prozessdefinition, Modellierungswerkzeugen und der Work- 
flow Engine (Ausführungsumgebung) 
e Benutzungsschnittstelle (Schnittstelle 2) 
APIs für Clients, um Dienste von der Workflow Engine anzufordern, damit der 
Prozessfortschritt und die Aktionen kontrolliert werden können. 
e Applikations-Schnittstelle (Schnittstelle 3) 
APIs, die der Workflow Engine erlauben, Applikationen aufzurufen und zu nutzen. 
e Workflow-Management-System-Schnittstelle (Schnittstelle 4) 
Standard-Schnittstelle für den Austausch mit anderen Workflow-Systemen 
e Administration und Monitoring (Schnittstelle 5) 
Schnittstelle für Werkzeuge zur Kontrolle der Prozesse und zur Überwachung 


Die wesentlichen Komponenten im Referenzsystem der WfMC sind der Workflow 
Enactment! Service und die Workflow Engine. Die Aktionen und ihre Reihenfolge wer- 
den in der Prozessdefinition festgelegt und durch die Workflow Engine gesteuert. 

In einem Unternehmen laufen in der Regel mehrere Instanzen eines Geschäfts- 
prozesses gleichzeitig ab. Eine Prozessinstanz entsteht, wenn die Ausführung eines 
Geschäftsprozesses durch das dafür definierte Ereignis angestoßen wird. Prozessinstanzen 


"Enactment steht für Umsetzung, Inkraftsetzung. 
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folgen der einheitlichen Prozessbeschreibung, werden aber unabhängig voneinander aus- 
geführt. 

Beispielsweise können zwei verschiedene Kunden eine Bestellung tätigen. Jeder die- 
ser individuellen Kundenaufträge erzeugt eine eigenständig abzuwickelnde Instanz des 
Geschäftsprozesses „Auftragsbearbeitung“. 

Das Management der einzelnen Instanzen übernimmt das Workflow Enactment Sys- 
tem mithilfe von Workflow Engines. Eine Workflow Engine stellt die Ausführungs- 
umgebung für eine Workflow-Instanz zur Verfügung. Ihre wesentlichen Aufgaben sind: 


e Einordnung der Instanz in das organisatorische Umfeld 

e Interpretation der Prozessdefinition 

e Kontrolle der Prozessinstanzen 

e Navigation zwischen sequenziellen oder parallelen Prozessaktivitäten 
e Interpretation von Prozessdaten 

e Identifikation der Benutzungsschnittstellen 

e Verknüpfung mit anderen Programmen/Anwendungssystemen 

e Verknüpfung mit anderen Workflowsystemen 

e Übergeordnete Kontrollfunktion 


Ein Workflow Enactment Service ist ein Dienst, der eine oder mehrere Workflow Engines 
startet, verwaltet und ausführt. Über Applikationsschnittstellen greifen Workflow-Systeme 
auf Funktionen von Anwendungssystemen zu, die in einem Prozess vorgesehene Auf- 
gaben ausführen. 

Ein Worklist Handler ist eine Komponente, welche die Benutzer in einen Prozess ein- 
bindet. Er kann Teil eines Workflow-Management-Systems sein, oder von einem Work- 
flow-Experten definiert und programmiert werden. Durch den Worklist Handler wissen 
die beteiligten Aufgabenträger, in welcher Prozessinstanz sie welche Aufgaben zu erledi- 
gen haben. 

Damit Benutzer bei der Bearbeitung von Prozessinstanzen eine einheitliche Arbeits- 
oberfläche haben, können Workflow-Funktionen in andere gebräuchliche Anwendungen 
eingebettet werden, beispielsweise in ein E-Mail-Programm. Für eine solche Integration 
muss zwischen dem Workflow Enactment Service und den anderen Anwendungen ein 
Kommunikationsmechanismus bestehen. 

Die Referenzarchitektur sieht auch eine Schnittstelle für Administration und Monito- 
ring vor. Dort anknüpfende Software dient der Überwachung des gleichzeitigen Ablaufs 
verschiedener Instanzen von mehreren Geschäftsprozessen. Dieses Monitoring bezieht 
sich zum einen auf die fachliche Ebene der Abwicklung der Geschäftsfälle, beispiels- 
weise mit der Erfassung und Auswertung von Antwort- und Bearbeitungszeiten (vgl. 
Abschn. 6.3.3). Zum anderen sind auf der technischen Ebene die verwendeten IT-Sys- 
teme zu überwachen, etwa bezüglich Last- und Fehlverhalten. 

Die meisten derzeit am Markt angebotenen Workflow-Systeme unterstützen nur die 
Prozessorchestrierung, d.h. einen einzigen Kontrollfluss von Aufgaben. Für BPMN 
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bedeutet dies, dass ein Workflow-System nur die Funktionen in einem Pool ausführen 
kann. Werden in einer BPMN-basierten Prozessbeschreibung mehrere Pools verwendet, 
ist für jeden Pool eine eigene Workflow Engine nötig. Diese Workflow Engines müs- 
sen dann in der Regel durch Programmierung über die Schnittstelle 4 verbunden wer- 
den. Insbesondere wenn ein Prozess auf einer verteilten Infrastruktur ausgeführt werden 
soll, können solche Strukturen aufwendig und kostenintensiv werden, da viele Software- 
hersteller Lizenzgebühren für jede installierte Instanz der Workflow Engine berechnen. 
Damit steigen neben den technischen Schwierigkeiten auch die Kosten. 

Subjektorientierte Prozessbeschreibungen sind Prozesschoreografien, d. h. die Subjekte 
werden unabhängig voneinander parallel ausgeführt, ohne dass es eine zentrale Steuerung 
für alle Subjekte gibt. Zur Koordination ihrer einzelnen Tätigkeiten tauschen die Subjekte 
asynchron Nachrichten aus. Eine Ausführungsumgebung für subjektorientiert definierte 
Prozesse ist deshalb genau genommen ein sogenanntes Multiworkflow-System. Darin 
entspricht jedes Subjekt einer Orchestrierung, die von einem eigenen Workflow-System 
ausgeführt wird. Den asynchronen Nachrichtenaustausch zwischen mehreren Work- 
flow-Systemen wird im subjektorientierten Prozessmanagement mithilfe des Input- 
Pool-Konzepts realisiert. Für S-BPM wurde eine Reihe von Multiworkflow-Systemen 
entwickelt [9]. 


Kombination Physik-IT: Cyber Physical Systems 
In einem Prozess können Handelnde auch Maschinen sein, welche Aufgaben, rein mecha- 
nisch oder elektrisch gesteuert, vollautomatisch ohne menschliches Eingreifen erledigen. 

Die Maschinensteuerung erfolgt mechanisch, elektromechanische oder, bei den 
bereits angesprochenen Embedded Systems, zunehmend rechner- und softwarebasiert. 
Sensoren kontrollieren den physikalischen Zustand von Maschine inkl. Umgebungs- 
bedingungen, und Aktoren wie Stellmotoren, Schalter, Regler usw. greifen in den Betrieb 
der Maschine ein. Die Steuer-Software bestimmt weitgehend das Geschehen auf und an 
den intelligenten Maschinen sowie deren vertikale und horizontale Kommunikation mit 
anderen Systemen. 

Maschinen kommunizieren untereinander nicht nur durch den Austausch von Daten, 
sondern auch durch das Weiterleiten und Empfangen von physikalischen Artefakten. Die 
Nachricht „Zu entgratendes Werkstück“ kann dadurch realisiert sein, dass ein Werkstück 
von einer spanabhebenden Fertigungsmaschine automatisch weitertransportiert wird zu 
einer Maschine, die Kanten entgratet. Parallel dazu können bei der Entgratungsmaschine 
zusätzlich Nachrichten eintreffen, die eine nähere Beschreibung des Werkstücks ent- 
halten sowie die Art der Entgratung spezifizieren. 

Kombinationen aus physikalischen und informationstechnischen Komponen- 
ten werden als Cyber Physical Systems (CPS) bezeichnet. Da sie Produktions- und 
Geschäftsprozesse zusammenführen sind sie von besondere Bedeutung für Industrie 
4.0-Anwendungen. 

In BPMN kann der Modellierer einen Task, der von einer Kombination aus Mensch 
und IT ausgeführt wird, als Service Task modellieren, und eine intelligente Maschine 
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als eigenen Prozess in einem Pool beschreiben. Gibt es eine entsprechende Anzahl von 
Maschinen, die in einer komplexen Fertigungssituation zusammenarbeiten, so kann die 
Verwendung von zahlreichen Pools in BPMN zu Darstellungsproblemen führen. Der 
Grund liegt in der horizontalen Anordnung der Pools, sodass bei einer größeren Anzahl 
die Nachrichtenkanten zwangsläufig Pools kreuzen müssen, was Unübersichtlichkeit 
bewirkt. In S-BPM wird eine Maschine dagegen immer als Subjekt modelliert, da erst 
bei der Implementierung entschieden wird, durch welche Art von Aufgabenträger das 
Subjekt ausgeführt wird. 

Wird in einem Prozess ein physikalischer Aufgabenträger verwendet, kann es von die- 
sem Prozess nicht beliebig viele parallele Instanzen geben. Eine physikalische Einheit 
kann nicht logisch aufgespalten werden, wie dies bei Aufgabenträgern der IT oder Men- 
schen möglich ist. Auf diese Thematik werden wir im Abschn. 6.3.2 näher eingehen. 


Kombination Mensch-Physik-IT 
Auch beim Einsatz intelligenter Maschinen gibt es Szenarien, bei denen der Mensch 
bestimmte Aufgaben ausführt. Beispielsweise erhält eine Maschine das Werkstück über 
ein Transportsystem und die dazugehörigen Informationen als Nachricht. Die Maschine 
und ein Bediener führen die vorgesehenen Aufgaben gemäß den Angaben in den Begleit- 
informationen zusammen aus. Der Bediener bestätigt die Erledigung seiner Arbeiten über 
eine Benutzungsschnittstelle. Anschließend wird das Werkstück abtransportiert, und die 
aktualisierten Begleitinformationen wird an weitere involvierte Handelnde übermittelt. 

In solchen Situationen ist es das Bestreben, den Anteil der menschlichen Arbeit weiter 
zu reduzieren und durch ausgefeiltere Mechanik oder verbesserte Embedded Systems zu 
ersetzen. Dabei muss es nicht zwingend notwendig sein, die Prozesslogik zu verändern. 


6.3 Betrieb und Monitoring 
6.3.1 Inbetriebnahme 


Nach der Festlegung der Aufgabenträger und der Implementierung(sunterstützung) der 
Handlungen gilt es den Prozess in Betrieb zu nehmen. 

Dazu müssen die Aufgabenträger vorbereitet werden, indem die physikalische und 
informationstechnische Infrastruktur aufgebaut und die menschlichen Aufgabenträger 
geschult werden. Informationstechnische Aufgabenträger werden mit den jeweiligen Pro- 
grammen geladen und die Mechanik von Maschinen entsprechend eingestellt. 

Bei der Inbetriebnahme ist es wichtig, die Verknüpfung mit anderen Prozessen her- 
zustellen. In einem Unternehmen sind Prozesse in ein zusammenhängendes Netz- 
werk von Prozessen eingebunden. Es sollte keine isolierten Prozesse geben. Wird z. B. 
ein neuer Prozess Versandvorbereitung eingeführt, muss dieser verknüpft sein mit dem 
Prozess Auftragsannahme. Bei kommunikationsorientierten Prozessbeschreibungen 
geschieht dies einfach durch den Austausch von Nachrichten. Ein andere Möglichkeit 
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sind gemeinsame Daten, d. h. Prozesse schreiben Daten, die andere Prozesse benötigen 
in eine gemeinsam genutzte Datenbank. 

Nach den Vorbereitungsarbeiten sollte der Prozess als Gesamtkonstrukt getestet wer- 
den. Vorteilhaft dazu wäre eine Testumgebung, die ein möglichst realistisches Abbild 
der Einsatzumgebung darstellt. Allerdings ist diese Wunschsituation aus Kostengründen 
nicht oft gegeben. 

Unabhängig davon empfiehlt es sich den Prozess Schritt für Schritt einzuführen. 
Dabei ist von Vorteil, wenn ein Prozess als ein lose gekoppeltes System von kommuni- 
zierenden Aufgabenträgern beschrieben und umgesetzt wurde. Die einzelnen Handlungs- 
stränge für die Handlungsträger können Schritt für Schritt in Betrieb genommen werden. 
Da sie durch den asynchronen Nachrichtenaustausch nur lose miteinander gekoppelt 
sind, kann man andere Aufgabenträger zunächst einfach simulieren. Bei BPMN wird 
somit Pool für Pool in Betrieb genommen. Sind die Pools allerdings sehr komplex mit 
mehreren Swim Lanes, gestaltet sich die Inbetriebnahme ebenfalls als komplex. Bei 
der Verwendung von S-BPM kann ein System durch das schrittweise Hinzunehmen der 
einzelnen Subjekte aufgebaut werden. 

Werden in BPMN nicht mehrere Pools verwendet, d. h. ein Prozess wird rein kontroll- 
flussorientiert definiert und implementiert, kann dieser auch nur insgesamt in Betrieb 
genommen werden. 

Bei Choreografien, d. h. bei der Verwendung von Subjekten bzw. mehrerer Pools kann 
der Prozess ausgeführt werden, obwohl z. B. bei einem Pool die Software noch fehler- 
haft ist. Die an diesen Pool gesendeten Nachrichten können ersatzweise von Menschen 
entgegengenommen, bearbeitet und das Ergebnis als Nachricht zurückgesendet wer- 
den. Die anderen Pools nehmen die beschriebene Ablauflogik wahr (beobachtbares Ver- 
halten), die aber noch nicht in der endgültigen Form implementiert ist. 


6.3.2 Prozessinstanzen 


Die konkrete Ausführung eines Prozesses wird als Prozessinstanz bezeichnet. Eine 
Prozessinstanz entsteht, wenn das Startereignis eintritt. Dies kann der Anruf eines Kun- 
den sein, der ein Produkt bestellen möchte. In diesem Fall kreiert ein Telefonverkäufer 
explizit eine Instanz indem er den digitalen Bestellvorgang startet und die notwendigen 
Daten eingibt. Bei Bestellungen in einem Online-Shop erfasst der Kunde die Auftrags- 
daten selbst und erzeugt eine Instanz, sobald er den Kauf bestätigt. Anschließend durch- 
läuft eine Instanz in beiden Fällen die gemäß der definierten Prozesslogik vorgesehenen 
Bearbeitungsschritte und -stellen. 

Da in einem Unternehmen normalerweise zu einem bestimmten Zeitpunkt meh- 
rere Bestellungen vorliegen, existieren gleichzeitig mehrere voneinander unabhängige 
Prozessinstanzen, die sich in verschiedenen Bearbeitungsstadien befinden. Mitarbeiter 
eines Unternehmens sind in der Regel in mehrere Prozessinstanzen eingebunden und 
führen darin jeweils die für sie vorgesehenen Aufgaben aus. Sie teilen sozusagen 
jeder Prozessinstanz eine Zeitscheibe ihrer Arbeitszeit zu. Analog geschieht dies bei 
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IT-Systemen. Sowohl die Kapazität der Ressource Mensch als auch der IT-Systeme kann 
also in Zeitscheiben aufgeteilt werden, um mehrere Instanzen von gleichen oder unter- 
schiedlichen Prozessen zu bearbeiten. 

Bei physikalischen oder cyber-physikalischen Systemen ist dies nicht so ohne wei- 
teres möglich. Ein solches System kann zu einem Zeitpunkt nur in genau einer Instanz 
involviert sein. Eine Maschine kann nicht mehrfach instanziiert werden, sie ist eben nur 
einmal vorhanden. Erst wenn eine Maschine eine Aufgabe oder Aufgabenfolge in einer 
Prozessinstanz vollständig abgeschlossen hat kann sie für eine andere Prozessinstanz 
tätig werden. Zu einem bestimmten Zeitpunkt ist ein physikalisches System deshalb 
genau einer Prozessinstanz zugeordnet. 

Dieser Sachverhalt ist wichtig, wenn Prozesse, die problemlos instanziiert werden 
können, da sie keine physikalischen Aufgabenträger enthalten, mit Prozessen verknüpft 
werden, die physikalische Komponenten enthalten. Ein Fertigungssystem besteht nahezu 
vollständig aus physikalischen oder cyber-physikalischen Aufgabenträgern. Diese 
Prozesse werden zu Beginn instanziiert. Diese eine Instanz besteht dann bis die Ferti- 
gung abgeschaltet wird. Ein physikalischer Aufgabenträger kann nicht eine Zeitscheibe 
für eine Prozessinstanz 1 arbeiten, dann etwas für eine Prozess 2 tun, um danach wie- 
der für die Prozessinstanz 1 weiterzuarbeiten. Die Aktionen eines physikalischen Auf- 
gabenträgers für verschiedenen Prozessinstanzen wären nicht unabhängig voneinander. 
Soll beispielsweise ein Ventil für die Prozessinstanz 1 halb geöffnet werden und danach 
für die Prozessinstanz 2 ganz geöffnet werden dann wird natürlich auch für die Prozess- 
instanz 1 das Ventil ganz geöffnet, was aber nicht sein soll. 

Wird in BPMN eine Maschine einem Task zugeordnet und kann der zugeordnete Pool 
mehrfach instanziiert werden, so muss die Maschine zur Laufzeit immer einer einzelnen 
Instanz zugeordnet werden. Die Maschine muss immer wissen, für welche Instanz sie 
tätig ist, um die richtigen Begleitdaten aus dem allen Instanzen gemeinsamen Speicher zu 
holen, um dann aus dem Werkstückbehälter das zu bearbeitende Werkstück zu entnehmen. 

Bei S-BPM ist die Maschine dem entsprechenden Subjekt zugeordnet. Dieses emp- 
fängt das Werkstück und die Begleitdaten als Nachricht. Die Begleitdaten enthalten auch 
eine Identifikation der zugehörigen übergeordneten Prozessinstanz, in der Regel die Auf- 
tragsnummer. Damit weiß die Maschine, für welche Prozessinstanz sie nun arbeitet. Die 
Nachricht, mit der eine Maschine ihre Arbeit für beendet erklärt, geht an eine Subjekt- 
instanz in der beauftragenden Prozessinstanz. 


6.3.3 Monitoring 


Prozessbeteiligte führen im Tagesgeschäft Geschäftsprozesse gemäß des modellierten 
Designs in der bei der Umsetzung geschaffenen Umgebung aus Personal- und techni- 
schen Ressourcen aus (vgl. Abschn. 6.2). 

Jeder anfallende Geschäftsvorfall durchläuft als Instanz diese Ausführungsumgebung. 
Dabei zeichnen Transaktionssysteme wie Enterprise-Resource-Planning-Anwendungen 
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(ERP) oder Workflow Engines das Verhalten der Instanz in Form von Einträgen in einem 
Log File (Event Log, Audit Log) auf. Ein Log-Datensatz enthält u. a. eine eindeutige 
Vorgangsidentifikation, Teilschrittidentifikation und Zeitstempel für Beginn und Ende. 
So entstehen Rohdaten für die Berechnung von Prozesskennzahlen (Process Performance 
Indicators, PPIs). 

Verlässliche Managementinformation auf Basis solcher Kennzahlen ist die Voraus- 
setzung für eine kontinuierliche Anpassung der Prozessgestaltung im Hinblick auf 
höhere Zielerreichungsgrade. Die periodische Ex-post-Auswertung über eine Vielzahl 
von Instanzen über längere Zeiträume wie Wochen, Monate, Quartale etc. dient dabei 
vorwiegend der Erkennung struktureller Verbesserungspotenziale, beispielsweise bezüg- 
lich planmäßigem Personaleinsatz, Ablauflogik oder Grad der IT-Abdeckung. Dieses 
traditionelle Monitoring und Reporting folgt dem Konzept der Business Intelligence mit 
dem Prinzip „Store and analyze“ und den Methoden des Data und Process Mining. Dar- 
aus resultierende Veränderungen sind eher mittel- und langfristiger Natur. 

Um auch den steigenden Echtzeitanforderungen Rechnung zu tragen, wird das tra- 
ditionelle Prozessmonitoring deshalb mittlerweile ergänzt durch das Business Activity 
Monitoring (BAM), welches ereignisgetrieben nahezu in Echtzeit Daten auswertet, zeit- 
nah Ergebnisse meldet und damit kurzfristige, instanzbezogene Maßnahmen ermöglicht 
[10]. Beispiel wäre die bevorzugte weitere Bearbeitung der Bestellinstanz eines A-Kun- 
den, wenn das System erkennt und meldet, dass diese an einem Messpunkt hinter dem 
dort üblichen Bearbeitungsfortschritt hinterherhinkt und deshalb der zugesagte Liefer- 
termin nicht zu halten ist (predictive analysis). 

BAM nutzt das Konzept des Complex Event Processing (CEP) mit dem Prinzip 
„Stream and analyze“ und Stream-Mining-Methoden. Dies bedeutet, dass das System 
im Strom von aufgezeichneten einzelnen Vorkommnissen (z. B. gesetzte Zeitstempel, 
passierte Messpunkte) permanent nach Mustern für komplexe Ereignisse sucht, die 
erst durch die Verknüpfung der einzelnen Ereignisse Relevanz für bestimmte Zwe- 
cke erlangen. Typisches Beispiel ist die Erfassung zweier Transaktionen mit derselben 
Kreditkarte in Hamburg und New York. Diese einfachen Einzelereignisse (low level 
events) werden im Ereignisstrom als normale Vorgänge registriert. Das CEP-System 
kombiniert sie erst zu einem komplexen Ereignis (complex event), wenn beide Trans- 
aktionen innerhalb eines kurzen Zeitraum stattfinden, im Beispiel etwa 3 h. In diesem 
Fall würde ein Ereignismuster aus geografischem und Zeitabstand zur Klassifikation als 
komplexer Event „angenommener Kreditkartenmissbrauch“ führen. 

Business Activity Monitoring soll permanent und gleichzeitig eine Vielzahl von 
Datenquellen überwachen. Zu den Erzeugern von Ereignisdaten gehören Anwendungen, 
die Prozessinstanzen verarbeiten (z.B. ERP, CRM, Workflow Engines) sowie 
andere Informationen von innerhalb oder außerhalb des Unternehmens liefern (z. B. 
Umgebungsbedingungen, Wetter- und Verkehrsdaten). Zunehmend zählen dazu auch 
(Sensor)Daten, die smarte Geräten und Einrichtungen im Internet of Things produzieren. 
BAM analysiert und aggregiert die Datenflut mithilfe definierter Regeln und übermittelt 
Ergebnisse an berechtigte und interessierte Empfänger. 


6.3 Betrieb und Monitoring 217 


Criteria for Process Monitoring 


Comparison 
Traditional complements Business Activity Monitoring 
Monitoring 


Measurement Instance and other data from heterogenous sources 


Event 
(push) 


Request 
(pull) 


Analysis Trigger 
& 


point in 
time 


Real-time/near real-time 
(low latency) 


Ex post 


Concepts Business Intelligence Complex Event Processing 
& Operational 
Methods Intelligence 


Store and analyze Stream and analyze 


Classic Database Requests Continous Database Requests 


OLAP/Data Mining/Process Mining Stream Mining 


Reporting & Ad hoc 
Presentation 


Periodically jPermanently (very short refreshing 


intervals) & by exception 


Addressee: upper & top management 


Cause Analysis, F 
Decision, Action Usually mid-term/long-term 


Abb. 6.4 Eigenschaften von traditionellem und Business Activity Monitoring 


Addressee: operational management 
process participants 


Immediately/short-term 


Abb. 6.4 stellt das traditionelle und das komplementäre Business Activity Monito- 
ring nebeneinander. Als Vergleichsmerkmal dienen die in der linken Spalte aufgeführten 
Aktivitäten [10]. 

Zeitpunkt und Art der Verwertung der aufgezeichneten/registrierten Daten hängen von 
der Ausgestaltung des Monitoring und Reporting gemäß der Anwenderanforderungen 
ab. Beim Pull-Prinzip ruft der Anwender die von ihm gewünschte Auswertung zu einem 
beliebigen Zeitpunkt ab. Nach dem Push-Prinzip erzeugt das System zeitgesteuert z. B. 
täglich, wöchentlich, monatlich, quartalsweise zu festgelegten Zeiten Auswertungen und 
informiert den vordefinierten Empfängerkreis davon. Beim Überschreiten von Grenz- 
werten oder Toleranzschwellen für Process Performance Indicators einzelner Instanzen 
zur Laufzeit können, ebenfalls per Push, Alarmmeldungen an Verantwortliche über- 
mittelt oder andere Vorgänge gestartet werden, z. B. ein umfangreicher Eskalations- 
prozess mit Korrekturmaßnahmen für den betreffenden Fall. 

Als Präsentationsform für die Auswertungen dominieren Management Cockpits mit 
Instrumententafeln (Dashboards). Dort finden sich meist Darstellungen in Form von 
Tachometern, Ampeln und Balken- oder Kreisdiagrammen. Für platzsparende Anzeigen 
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Abb. 6.5 Instanzbericht (Übersicht) 
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Abb. 6.6 Instanzbericht (Einzelne Instanz) 


mit hoher Informationsdichte kommen auch Wortgrafiken wie Sparklines oder Bullet 
Graphs zum Einsatz. Beispiele für Auswertungen und ihre Darstellung sind: 


e Durchlaufzeit von laufenden und abgeschlossenen Instanzen. Der Status wird in 
Ampelfarben ausgedrückt, je nach Abweichung von definierten Sollwerten bzw. 
Toleranzbereichen (vgl. Abb. 6.5). 

e Durchlaufzeit einer laufenden Instanz (absoluter Wert und Vergleich mit Durchschnitt, 
chronologischer Ablauf und Dauer der Einzelschritte der Prozessbeteiligten (vgl. 
Abb. 6.6). 
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e Abfolge der Prozessschritte einer laufenden Instanz mit Zeitstempeln für den 
Abschluss eines Schritts, d. h. für den Übergang von einem Zustand in den nächsten 
(vgl. Abb. 6.7). 

e Anzahl von Instanzen eines Prozesses pro Zeiteinheit, minimale, durchschnittliche 
und maximale Bearbeitungszeit pro Prozessbeteiligtem und -schritt (vgl. Abb. 6.8). 


6.3.4 Process Mining 


Eine spezielle Form der Auswertung von Prozessdaten stellt das Process Mining dar. 
Dabei werden Log Files genutzt, um aus den Transaktionsdaten zentraler IT-Systeme 
(u.a. ERP, CRM und SCM) prozessbezogene Informationen zu extrahieren und so den 
tatsächlichen Prozessablauf visuell rekonstruieren und analysieren zu können. Dadurch 
können Erkenntnisse über das wirkliche Verhalten von abgewickelten Prozessinstanzen 
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Abb. 6.7 Instanzbericht (aktueller Bearbeitungsstand) 
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Abb. 6.8 Prozessbericht 


gewonnen werden [11]. Häufig analysierte Unternehmensprozesse sind: Einkauf, Verkauf, 
Kreditoren-/Debitorenbuchhaltung, Ticketing-Systeme (z. B. im IT-Service Management). 
Ein Event Log enthält sequenziell aufgezeichnete Ereignisse (trace) mit Attributen 


wie Fallnummer (caseID), Aktivität (activity), Zeitstempel (timestamp 
Einheit (resource) und bearbeitete Geschäftsobjekte (data elements). J 


), ausführender 
e nach Prozess 


können weitere Informationen dazu kommen, wie z. B. der Name eines Kunden oder 
Lieferanten, Bestellmenge und -wert, Liefermenge etc. In Abb. 6.9 ist ausschnittsweise 


ein Beispiel für ein Event Log dargestellt. 


Mit Bezug solcher Protokolldaten für die Prozessausführung zu Prozessmodellen las- 


sen sich drei wesentliche Arten von Process Mining identifizieren [11]: 


e Entdeckung (Discovery): dabei rekonstruieren Algorithmen aus den Log-Daten ohne 
weitere Informationen den tatsächlichen Prozessablauf und dessen vielfältige Varian- 


ten. Damit lassen sich bereits gelebte, aber noch nicht dokumentierte Prozesse formal 


beschreiben. 


Konformität (Conformance): dabei vergleichen Algorithmen ein vorhandenes, gülti- 


ges Prozessmodell mit dem tatsächlichen Ablauf wie er aus den Log-Daten abgeleitet 
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CaselD Activity Timestamp 


10001 01-01-2009, 8:35 am 
10001 03-01-2009, 12:13 am 
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Abb. 6.9 Ausschnitt aus Event Log (Abbildung übernommen mit Genehmigung der Celonis SE) 


wird. Festgestellte Abweichungen können Anhaltspunkte für Optimierungen liefern 
und Missbrauch oder Verstöße gegen Compliance-Regeln aufdecken. 

e Erweiterung (Enhancement): hier werden bestehende Modelle an die Realität der Vor- 
gangsbearbeitung angepasst (Repair) oder dem Modell weitere Perspektiven wie Zeit- 
dauern hinzugefügt (Extension). 


Insbesondere die Überprüfung der Konformität sollte möglichst zur Laufzeit von Ins- 
tanzen im Rahmen des Business Activity Monitoring durchgeführt werden, um Verstöße 
zeitnah zu entdecken und deren Folgen mildern zu können (z. B. Stoppen einer Über- 
weisung bei Unregelmäßigkeiten bei der Zahlungsfreigabe). 

Das folgende Beispiel ist der Process-Mining Lösung der Celonis SE (www.celo- 
nis.com) entnommen. Es zeigt ausgewählte Mining-Ergebnisse für einen Bestellab- 
wicklungsprozess (Purchase to-Pay), der mit einem ERP-System abgewickelt wird. Die 
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Analyse des dazugehörigen Event Logs für einen bestimmten Zeitraum hat folgende 
Information hervorgebracht (vgl. Abb. 6.10): 


e 279.020 Instanzen des Prozesses mit einem Nettobestellwert von 539.180.072 € 

e 107.688 Instanzen folgten dem normalen Ablauf des Prozesses (Happy Path), begin- 
nend mit dem Erstellen einer Bestellanforderung und endend mit der Verbuchung der 
Rechnung (siehe Fallnummer 10.002 in Abb. 6.9). Die durchschnittliche Durchlauf- 
zeit beträgt 27 Tage Diese Prozessvariante 1 deckt 39 % aller Instanzen ab, daneben 
existieren 527 andere Varianten. 


Erweitert man den Betrachtungsraum beispielsweise auf die sieben am häufigsten vor- 
kommenden Prozessvarianten, sieht man, dass damit 83 % aller Instanzen abgedeckt 
sind. Im Prozessgraphen sind jetzt auch die sieben Pfade mit den dazugehörigen Häufig- 
keiten sichtbar (vgl. Abb. 6.11). Alternativ können auch die durchschnittlichen Dauern 
der Wege und Zustandsübergänge angezeigt werden. Bezüglich des Ablaufs fällt außer- 
dem auf, dass eine nicht geringe Zahl von Instanzen (18.938) mit dem Scan der Rech- 
nung beginnt und erst dann eine Bestellung im System angelegt wird (siehe Fallnummer 
10.003 in Abb. 6.9). Dies ist ein Indiz für sog. Maverick Buying, d. h. die Beschaffung 
von Fachabteilungen am Einkauf vorbei. Diesem i. d. R. unerwünschten Prozessver- 
halten kann im nächsten Schritt gezielt nachgegangen werden, um dessen Ursachen zu 
beseitigen. 

Mit der Einblendung zusätzlicher Informationen lassen sich Prozesse tiefergehend 
untersuchen. Abb. 6.12 gibt beispielsweise Auskunft über die auf Monate verteilte 
Anzahl von Bestellungsinstanzen mit den jeweiligen Wertangaben sowie deren Ver- 
teilung auf Lieferanten. 
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Abb. 6.10 Übersicht über Prozessvarianten (rechts) und Happy Path (links) (Screenshot des 
Celonis Viewer/Variant Explorer mit Genehmigung der Celonis SE) 
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Abb. 6.11 Anzeige der sieben häufigsten Prozessvarianten (Screenshot des Celonis Viewer/ 
Variant Explorer mit Genehmigung der Celonis SE) 
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Abb. 6.12 Einblendung zusätzlicher Information (Screenshot des Celonis Viewer/Analysis mit 
Genehmigung der Celonis SE) 


Die vorgestellten Analysen betreffen nur einen kleinen Ausschnitt der vielfältigen 
Nutzungsmöglichkeiten der Celonis-Umgebung. So können die Anwender über die 
vom System vorgesehenen Auswertungen hinaus auf Basis ihrer individuellen Daten- 
modelle eigene Auswertungen durch Rückgriff auf eine Vielzahl vorhandener Ana- 
lysekomponenten (wie verschiedene Diagrammtypen, Prozesskennzahlen und 
OLAP-Tabellen) definieren. Außerdem erlaubt die Software die Ausführung eigener 
Prozessauswertungen mithilfe der Process Query Language (PQL). 
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Zusätzliche Funktionen erlauben etwa die Analyse der Konformität des tatsächlichen 
mit dem im Modell vorgesehenen Ablauf (Konformität) oder die parallele Visualisierung 
und damit die Gegenüberstellung unterschiedlicher Verhalten desselben Prozesses bei- 
spielsweise in zwei Niederlassungen (Benchmarking). 

Die Zukunft des Process Mining liegt in der Kombination der Prozessanalyse mit 
intelligenten Algorithmen. So integriert beispielsweise die Celonis Proactive Insights 
Engine (Pi) Machine Learning und Artificial Intelligence Techniken, und identifiziert für 
den Nutzer automatisch Schwachstellen im Prozess sowie deren Ursachen [12]. Darauf 
aufbauend erhält der Nutzer zudem intelligente Empfehlungen zur Prozessverbesserung. 


6.3.5 Kontinuierliche Wartung 


Ziel von Monitoring, Auswertung und Reporting des Prozessverhaltens ist es, 
Managementinformation zum Prozessverhalten zu erzeugen und bereitzustellen. Die 
Adressaten können diese analysieren, Ursachen für Abweichungen von Zielwerten 
erforschen und kurz-, mittel- und langfristige Handlungsbedarfe und Maßnahmen zur 
Restrukturierung daraus ableiten. 

Die folgenden Ausführungen erläutern typische Veränderungen der Prozess- 
gestaltung, welche sich positiv auf das Prozessverhalten im Sinne einer Optimierung 
auswirken sollen. Wir beziehen uns dabei exemplarisch auf das Kreditantragsbeispiel aus 
Abschn. 4.2.2. 


e Parallelisieren und überlappte Ausführung. Logisch und technisch voneinander 
unabhängige Aktivitäten können ganz oder teilweise gleichzeitig und von ver- 
schiedenen Aufgabenträgern ausgeführt werden. Zwar kann die Zahl unterschied- 
licher Aktivitäten durch die Aufspaltung ansteigen, die Parallelisierung bewirkt aber 
oft eine Prozessbeschleunigung. So könnte ein Prüfschritt bei der Kreditantragsbe- 
arbeitung in die dann parallel vorgenommene Bonitätsprüfung des Kunden und Wert- 
haltigkeitsprüfung des Finanzierungsobjekts zerlegt werden. 

e Zusammenfassen von Aktivitäten. Zusammenfassen als Gegenteil von Auf- 
spaltung bedeutet, dass ursprünglich getrennt und von verschiedenen Aufgaben- 
trägern bearbeitete Aktivitäten nun durch einen Aufgabenträger ausgeführt werden. 
Diese Reintegration von Aufgaben führt Arbeitsteilung zurück und verringert dadurch 
beispielsweise Schnittstellen. Die Zahl der Aktivitäten in einem Geschäftsprozess 
und seiner Darstellung nimmt durch die Zusammenfassung ab und die Anordnungs- 
beziehungen zwischen den Aktivitäten des Geschäftsprozesses ändern sich. Im 
Kreditantragsprozess könnte die Zusammenfassung der beiden Prüfschritte wieder 
sinnvoll sein, wenn die weiter unten beschriebene Automatisierung der Kundenboni- 
tätsprüfung den Zeitgewinn durch Parallelisierung relativiert. 
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e Änderung der Reihenfolge. Die Anordnungsbeziehungen zwischen den Aktivi- 
täten, oder zwischen Gruppen oder Bündeln von Aktivitäten, können eventuell ver- 
tauscht werden, was zeitliche, kostenmäßige oder kapazitätsmäßige Vorteile haben 
kann. Beim Kreditantragsbeispiel sollte die Prüfung der Bonität der Bewertung des 
Finanzierungsobjekts vorgezogen werden, denn letztere ist hinfällig bzw. der ganze 
Prozess endet, wenn der Interessent nicht kreditwürdig ist. Eine Sequenz der Prüfun- 
gen steht im Gegensatz zu der Parallelisierungsoption. Um eine Entscheidung für eine 
der Varianten zu treffen, wäre die Information hilfreich, wie oft ein Antrag wegen 
mangelnder Bonität abgelehnt wird und damit im Falle der parallelen Objektprüfung 
Ressourcen verschwendet werden. 

e Elimination von Aktivitäten. Verbale Diskussionen, Process Mining, Pfadanalyse 
und Simulationsexperimente geben Hinweise auf nicht benötigte Aktivitäten (tote 
Pfade), sehr selten ausgeführte Aktivitäten, auf Aktivitäten, bei denen kaum eine 
Wertschöpfung erzielt wird oder die unwirtschaftlich sind. Die Zahl der Aktivitäten 
eines Prozesses nimmt durch die Elimination ab und die Struktur der Anordnungs- 
beziehungen ändert sich. Beispiel für eine Elimination wenig wertschöpfender 
Aktivtäten könnte das in Abschn. 4.2.8.2 angesprochene Weglassen der zusätzlichen 
Genehmigung eines Kreditantrags über 200.000 € durch die Abteilungsleitung sein. 

e Elimination oder Reduzierung von Zyklen. Wenn Geschäftstransaktionen Zyklen 
von Aktivitäten mehrfach durchlaufen, verlängert dies gewöhnlich die Durchlauf- 
zeiten der Prozesse und führt oft zu Wartezeiten bei der Ausführung. Mit der Pfad- 
analyse können solche Zyklen identifiziert und lokalisiert und möglicherweise durch 
Änderung der Prozessgestaltung eliminiert werden. Bei der Kreditantragsbearbeitung 
kann es beispielsweise immer wieder zu Nachfragen der Sachbearbeiter beim Inte- 
ressenten kommen, weil Informationen zur Beurteilung des Finanzierungsvorhabens 
fehlen. Sieht das elektronische Antragsformular Mussfelder und Anhänge für ent- 
sprechende Angaben vor, kann die Steuerung die Abgabe verhindern, so lange Infor- 
mation fehlt. Damit ist zwar nicht sichergestellt, dass der Antragsteller die richtige 
Information vollständig und valide übermittelt, aber die Wahrscheinlichkeit dafür 
steigt und Rückfrageschleifen dürften seltener nötig sein. 

e Insourcing und Outsourcing. Unter Umständen ist es sinnvoll, in sich geschlossene 
Geschäftsprozesse oder einzelne Teile nicht in der eigenen Organisation, sondern von 
spezialisierten externen Dienstleistern ausführen zu lassen, welche dies z. B. aufgrund 
von Größenvorteilen (Economies of Scale) kostengünstiger und/oder schneller kön- 
nen. Damit lassen sich oft eigene Fixkosten durch variable Kosten für die Inanspruch- 
nahme der Leistungen des Partners ersetzen. Beispielsweise könnte die Bank anstatt 
eigene Sachverständige für die Immobilienbewertung zu beschäftigen fallweise ein 
Architekturbüro damit beauftragen. Bei entsprechenden Voraussetzungen kann auch 
der umgekehrte Weg Vorteile bringen, etwa, wenn bisher ausgelagerte Aktivitäten 
z. B. wegen des Wegfalls von Schnittstellen und Transaktionskosten intern wirtschaft- 
licher organisierbar sind. 
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e Automatisieren. Der technische Fortschritt eröffnet Möglichkeiten, manuelle Arbeits- 
schritte von IT-Anwendungen und Maschinen (z. B. Roboter) zu unterstützen oder 
komplett automatisiert ausführen zu lassen. Dies ist insbesondere für zeitintensive, 
wenig motivierende und fehlerträchtige Tätigkeiten relevant. Zur Realisierung von 
Automatisierungsoptionen gilt es, die Entwicklung und den Markt für entsprechende 
Technologien dauerhaft zu beobachten, um passende Lösungsbausteine identifizieren 
und diese in Prozessanpassungen einbeziehen zu können. Als Beispiel kann der para- 
metrisierbare Webservice der SCHUFA für die Auskunft über Kunden dienen, dessen 
Integration nicht nur Automatisierung fördert, sondern auch ein Beispiel für teilweises 
Outsourcing darstellt. 

e Reduktion von Schnittstellen. Arbeitsteilige Prozessabwicklung weist naturge- 
mäß Schnittstellen auf organisatorischer und technischer Ebene auf. Sie involviert 
verschiedene Organisationseinheiten und externe Partner, die oft mit uneinheit- 
lichen IT-Systemen und Arbeitsmitteln mitunter an verschiedene Medien gebundene 
Zwischenergebnisse erzeugen und austauschen. Folgen sind Medienbrüche und damit 
verbundene Doppelarbeit, Übertragungsfehler, Zeitverluste, Kosten usw. Eine Ver- 
ringerung der Schnittstellen wirkt diesen Nachteilen entgegen. Sie lässt sich durch 
organisatorische Veränderungen wie die Reintegration oder Eliminierung von Aktivi- 
täten und die Änderung der Zuordnung von Aufgaben zu Aufgabenträgern erzielen. 
Auf der technischen Ebene helfen integrierte IT-Systeme wie Enterprise-Resour- 
ce-Planning-Software und Workflow-Anwendungen. Beim Kreditantragsbeispiel hat 
die teilweise Verlagerung der Unterschriftenkompetenz auf die Sachbearbeitungs- 
ebene deren Aufgabenzuschnitt und denjenigen der Abteilungsleitung verändert. Als 
Konsequenz konnten ein Ablaufzweig eliminiert und die dazugehörigen Schnittstellen 
reduziert werden. 


Zu beachten ist, dass viele der genannten Optimierungsansätze interdependent sind, und 
deshalb immer Auswirkungen einer Maßnahme auf andere Faktoren der Gestaltung zu 
berücksichtigen sind. So kann beispielsweise das Outsourcing von Prozessteilen die 
Anzahl der Schnittstellen erhöhen und Aufwand für das Dienstleistungsmanagement 
verursachen. Diese Effekte wirken den Vorteilen der Auslagerung entgegen, sodass stets 
eine Abwägung nötig ist. 
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Praxisbeispiel 


Das folgende Fallbeispiel zeigt, wie einige der beschriebenen Konzepte, Methoden und 
Sprachen angewendet wurden, um einen für ein konkretes Unternehmen wesentlichen 
Prozess zu verbessern. Die Dokumentation des real durchgeführten Projekts macht deut- 
lich, dass sich die vorgestellten Aktivitäten nicht streng voneinander getrennt bearbeiten 
lassen, sondern sich in der Praxis oft überlappen und mit häufig wechselnden Schwer- 
punktbetrachtungen ineinander überfließen. Wir geben den Projektverlauf wieder, der 
von Christoph Moser stammt [1], und stellen mit den grau dargestellten Unterüber- 
schriften jeweils den Bezug zu den passenden Ausführungen in Kap. 1 bis Kap. 6 und 
den betroffenen Aktivitätsbündeln in Abb. 7.1 her. 


7.1 Ausgangsituation 


Analyse: Blick auf die „Welt“ ENGEL ist ein traditioneller Hersteller von Spritzgieß- 
maschinen aus Österreich und wurde 1945 von Ludwig Engel gegründet. Nach Ein- 
führung der ersten Spritzgießmaschine im Jahr 1952 hat sich ENGEL bis zum Jahr 2016 
mit einem Gesamtumsatz von 1,36 Mrd. EUR zum Weltmarktführer entwickelt. Das 
vollständig eigentümergeführte Unternehmen beschäftigt weltweit ca. 5900 Mitarbeiter 
in 9 Produktionswerken und über 85 Niederlassungen [2]. ENGEL ist ein stark kunden- 
orientiertes Unternehmen mit Fokus auf Flexibilität und Innovationen. 


Festlegung des Key Performance Indicators ausgehend vom Geschäftsmodell und der 
Strategie Die starke Fokussierung auf die Kundenbedürfnisse und die fortschreitende 
Entwicklung hin zu kürzeren Lieferzeiten führten zur Definition eines unternehmens- 
weiten Ziels: Reduzierung der Durchlaufzeit eines Prozesses für die Produktion aller 
Varianten einer Standardkomponente für Spritzgießmaschinen um 30 %. 
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Abb. 7.1 Wechsel zwischen 
den Aktivitäten im Fallbeispiel 
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< Situative Abfolgen und Iterationen > 


Ein Projektteam wurde geschaffen, um den bestehenden Prozess zu erheben, zu ana- 
lysieren und die erforderlichen Verbesserungen zu implementieren. Der erste Schritt 
eines Optimierungsprozesses ist die Abbildung des Ist-Status, um detailliertere Kennt- 
nisse über die Material- und Informationsflüsse sowie über alle Faktoren zu erhalten, 
die den betrachteten Prozess beeinflussen können. Zum Zeitpunkt des Projektstarts gab 
es kaum explizite Informationen zum Gesamtprozess, den detaillierten Prozessschritten 
oder den beteiligten Prozessakteuren. 


Analyse und Modellierung Zu Beginn war nur bekannt, dass sich der Prozess über zwei 
Produktionsstandorte in zwei verschiedenen Ländern (Fabrik A und Fabrik B) erstreckt 
und sich auf drei Produktgruppen bezieht: 


e Produkt 1: Der fertige Rahmen für die Spritzgussmaschine ist die Ausgangs- 
komponente jeder Maschine. Rahmen werden in Fabrik A zusammengebaut und 
bestehen unter anderem aus Produkt 2. Die Gesamtdurchlaufzeit für Produkt 1 umfasst 
die Auftragsabwicklung, Produktion und Lieferung von Komponenten (Produkt 2) und 
Teilkomponenten (Produkt 3). 

e Produkt 2: Der sogenannte „rohe“ Rahmen mit Öltank. Diese Hauptkomponente ist 
noch mechanisch unbearbeitet und wird in Fabrik B aus Produkt 3 zusammengebaut. 
Es gibt mehrere Dutzend Varianten von Produkt 2, abhängig von den Anforderungen 
der Kunden. 

e Produkt 3: Eine Art Bausatz aus Sägezuschnitten, welche in Fabrik A für die jeweilige 
Variante aus Stangenmaterial abgesägt werden. 


Abb. 7.2 zeigt ein grobes Schema der Lieferkette. Der Auslöser des Prozesses (break- 
ing point) ist der Auftrag der Fertigung der Spritzgießmaschine als internem Kunden 
(Customer) an Fabrik A. Diese sägt und liefert daraufhin die benötigten Teile (Produkt 
3) für Produkt 2 und beauftragt Fabrik B mit dessen Fertigung. Das Zwischenprodukt 
wird anschließend an Fabrik A geliefert, dort zusammengebaut und als Produkt 1 an die 
Montagelinie der Spritzgießmaschine geliefert. 
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Abb. 7.2 Lieferkette zwischen den Werken 


Der Prozess wird durch die Bestellungen gesteuert, die zwischen den Fabriken aus- 
getauscht werden. Wenn ein Auftrag in einer Fabrik eintrifft, wird er im ERP-System 
erfasst, und ein Fertigungsauftrag mit einem entsprechenden Lieferdatum erstellt. Erst 
nach dieser Erfassung ist der Auftrag produktiv wirksam. Wenn der Prozess bis zur 
Erfassung länger als 2 Arbeitstage dauert, trifft der Produktionsauftrag nicht rechtzeitig 
in der Produktion ein, da die Bestellvorlaufzeit auf zwei Arbeitstage festgelegt ist. In der 
Ausgangssituation wurden ca. 95 % aller Bestellungen zwischen den Fabriken zu spät 
erfasst, d. h. zwischen der Ankunft des Auftrages in der Fabrik und der tatsächlichen 
Erfassung vergingen mehr als zwei Arbeitstage. Diese Aufträge mussten dann manuell 
mit enormem Mehraufwand bearbeitet werden, was zu einer internen Liefertreue für Pro- 
dukt 2 von nur 39 % führte. Daraus resultierende Probleme bei der Produktionsplanung 
in der Fabrik A und Verzögerungen bei der Produktion von Produkt 1. 

Um das vorgegebene Ziel, die Durchlaufzeit um 30 % zu reduzieren, zu erreichen 

wurde ein Zeitrahmen von nur 10 Wochen vorgegeben. Die zwei Fabriken lagen in zwei 
verschiedenen Ländern mit unterschiedlichen Sprachen. 
Erste grobe Planung und Einordnung in die Enterprise Architecture: Keine grund- 
legenden Änderungen an der Organisation und der IT Der enge Zeitrahmen führte zu 
Einschränkungen für das Projekt: Neue Softwarelösungen oder Technologien können 
nicht eingeführt werden. Die Einführung solch weitreichender Veränderungen ist eine 
strategische Entscheidung und erfordert viel Personaleinsatz, Geld, Risikomanagement 
und Zeit. Dies bedeutete, dass Änderungen an den bestehenden Prozessen innerhalb 
der bestehenden Organisation und IT-Umgebung implementiert werden mussten. Erst 
nach Erreichen des ursprünglichen Projektziels können weitere, für zusätzliche Ver- 
besserungen notwendige Maßnahmen umgesetzt werden. 


7.2 _Durchgeführte Maßnahmen 


Prozessanalyse und Auswahl einer Modellierungssprache Mit Ausnahme einer ober- 
flächlichen Beschreibung des Materialflusses zwischen den Fabriken standen uns keine 
expliziten Prozessinformationen zur Verfügung. Da eine ordnungsgemäße Prozess- 
dokumentation für das Verständnis des Gesamtprozesses und die Identifizierung von 
Optimierungspotenzialen von grundlegender Bedeutung sind, bestand unser nächster 
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Schritt in der Dokumentation und Analyse des bereits etablierten Produktionsprozesses 
mittels Wertstromanalyse (WSA) [3], Dem Standardwerkzeug zur Dokumentation von 
Produktionsprozessen in unserem Unternehmen. 

Für eine erste Abbildung des Prozesses war es notwendig, ein geeignetes, repräsentatives 
Produkt auszuwählen, das die grundlegenden Produktionsschritte umfasst und den größten 
Teil des Materialflusses abdeckt. Wir kamen zu dem Schluss, eine Variante von Produkt 2 
für eine erste Ist-Analyse zu verwenden. Diese Auswahl basierte auf einer ABC-Analyse 
aller Produktvarianten und der entsprechenden Arbeitspläne. Die ausgewählte Variante für 
Produkt 2 macht 30 % der Gesamtproduktion aus, hatte die komplexesten Arbeitspläne und 
die längste Gesamtdurchlaufzeit der drei definierten Produktgruppen. 


Modellierung eines Teils des Ist-Prozesses Durch die Verfolgung des Materialflusses 
auf Werksebene durch beide Fabriken, die Erhebung relevanter KPIs (Lagerstand, 
Produktionsdurchlaufzeiten, Kundentakt etc.) und die Befragung der verantwortlichen 
Mitarbeiter konnten wir ein Wertstrommodell (WSM) für Produkt 2 erstellen. Abb. 7.3 
zeigt das WSM des Produktionsprozesses und seine hierarchische Struktur. 


Ergebnis der Analyse Die Ergebnisse der Wertstromanalyse waren wie folgt: 


e Der Produktionsprozess des Produkts 2 besteht aus zwei Hauptschritten: Herstellung 
des Basisrahmens und Herstellung des Öltanks. Sobald der Öltank fertiggestellt ist, 
wird er an den Rahmen montiert, um Produkt 2 herzustellen. 

e Der Öltank und der Rahmen werden getrennt gefertigt. Dies bedeutet, dass es 
keine Abstimmung zwischen den beiden Produktionslinien gibt, sobald der Auftrag 
gestartet wurde. 
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Abb. 7.3 Wertstromanalyse der Fertigung von Produkt 2 


7.2 Durchgeführte Maßnahmen 233 


e Aufgrund fehlender Produktionsplanung stapeln sich unfertige Bestände mit langen 
Wartezeiten. Nur ca. 10 % der gesamten Durchlaufzeit ist Produktionszeit. 

e Durch Optimierungen in der Produktionsplanung und den Arbeitsplänen kann die 
Durchlaufzeit verringert werden. Jedoch reichen die identifizierten Verbesserungen 
nicht aus, um das vorgegebene Ziel zu erreichen. 

e Wir haben allerdings hohes Potenzial im Informationsfluss der Auftragsverarbeitung 
identifiziert. 


Detaillierung des Prozessmodells Darüber hinaus wurden konkretere Informationen 
zum Bestellprozess zwischen den Fabriken gewonnen und die Prozessbeschreibung ent- 
sprechend erweitert: 


e Die Nachfrage nach Produkt 1 stammt von Fabrik A, von der aus eine Bestellung für 
die erforderliche Variante von Produkt 2 an Fabrik B gesendet wird. 

e Die Bestellung für Produkt 2 wird bearbeitet und die Beschaffung der erforderlichen 
Komponenten, darunter Produkt 3, beginnt. 

e Fabrik B bestellt jetzt Produkt 3 von Fabrik A. 

e Die Bestellung für Produkt 3 wird in Fabrik A erfasst, die Teile werden zugeschnitten 
und an Fabrik B verschickt. 

e Sobald Produkt 3 in Fabrik B ankommt, beginnt die Produktion von Produkt 2 und 
das fertige Produkt 2 wird danach an Fabrik A geliefert. 

e Sobald Produkt 2 in Fabrik A ankommt, beginnt die Fertigung von Produkt 1. 

e Dieser Prozess ist für jede Maschine gleich, unabhängig von der Variante von Produkt 1. 


Identifikation von Optimierungspotenzialen Durch die Wertstromanalyse konnten wir 
zwei Potenziale identifizieren: Die fehlende Produktionssynchronisierung und die nicht 
optimierte Auftragsabwicklung. Die Produktionssynchronisation ist allerdings direkt 
mit dem jeweiligen Produktionsplanungsprozess verknüpft. Bei einer kurzen Analyse 
des Planungsprozesses kamen wir zu dem Schluss, dass langfristige Verbesserungen 
nur möglich sind, wenn die Abläufe im Prozess Planung komplett reorganisiert und 
umstrukturiert werden und die Denkweise an sich verändert wird. Obwohl dies eine not- 
wendige Änderung gewesen wäre, konnten wir sie im Zeitrahmen des Projekts nicht 
umsetzen. Wir haben uns daher auf den Bestellprozess und sein Optimierungspotenzial 
konzentriert, da wir es als möglichen „Quick Win“ für unser Projekt identifiziert haben. 


Modellierung der noch fehlenden Aspekte Dies war der Einstiegspunkt für eine 
umfassende Prozesserhebung. Dem WSM fehlten jedoch noch relevante Prozess- 
informationen, um den Gesamtprozess und den entsprechenden Informationsfluss detail- 
liert zu beschreiben, beispielsweise 
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e keine Informationen über die Interaktionen zwischen den beteiligten Parteien 

e keine Informationen darüber, welche Schritte im Prozess automatisiert sind und wel- 
che Schritte manuell durchgeführt werden 

e keine konkreten Informationen zu den im SAP®-ERP-System verwendeten Trans- 
aktionen 

e keine Information über die Zeitlinien des Informationsflusses 

e keine Überprüfung der bereitgestellten Informationen 


Modellbildung, zusätzliche Modellierungssprache auswählen Da sich die WSA auf die 
Produktionsprozesse konzentriert und vor allem den Materialfluss zwischen den Prozess- 
schritten beschreibt, haben wir schnell erkannt, dass wir einen anderen Ansatz benötigen. 
Wir mussten eine zusätzliche Methode verwenden, um den Informationsfluss in einem 
Detailgrad zu beschreiben, der es uns erlaubt eine genaue Analyse durchzuführen. Der 
nächste Schritt bestand darin, ein Prozessmodell der in den Prozess involvierten Perso- 
nen und SAP®-Systeme sowie deren jeweiligen Interaktionen bzw. des Informations- 
flusses zu erstellen. 


Begründung warum subjektorientierte Modellierung hinzugenommen wurde Zur 
Ergänzung unseres bestehenden WSM haben wir das subjektorientiertes Geschäfts- 
prozessmanagement eingeführt [4]. Wir wählten S-BPM aufgrund unserer vergangenen 
Erfahrungen und der Probleme, die wir mit Flussdiagrammen bzw. Swimlane-Diagrammen 
hatten, die gelegentlich neben der WSA verwendet werden. In früheren Anwendungen von 
Swimlanes lieferten die Prozessmodelle entweder einen Überblick über den Prozess, waren 
aber damit nicht detailliert genug für eine gründliche Prozessanalyse, oder die Prozess- 
modelle waren so detailliert, dass es sehr schwierig wurde, den Überblick zu behalten. 
Darüber hinaus sind Swimlane-Modelle unserer Erfahrung nach nicht dazu geeignet, die 
beteiligten Individuen und deren Abhängigkeit voneinander in transparenter Form, ins- 
besondere bei mehr als fünf oder sechs Beteiligten, zu visualisieren. 


Beschreibung von S-BPM und verwendete Werkzeuge Die Erfahrung hat gezeigt, dass 
die an den Prozessen beteiligten Personen, ihre individuellen Ansätze, ihr Wissen und 
ihre Erfahrungen eine entscheidende Triebfeder für die Prozesse eines Unternehmens 
sind und für erfolgreiche Prozesse unerlässlich sind [5, 6]. Die Art und Weise, in der der 
Informationsfluss zwischen den Prozessakteuren organisiert ist, hat einen wesentlichen 
Einfluss auf die Geschäftsprozessleistung [7]. 

S-BPM konzentriert sich speziell auf die Darstellung von Prozessen aus der Sicht der 
beteiligten Prozessakteure, sogenannte „Subjekte“, und deren Interaktion in der Prozess- 
umgebung. Ein Subjekt kann eine Maschine, ein IT-System oder eine Person sein. Sub- 
jekte sind abstrakte Handelnde ohne Angabe wie sie implementiert sind. 

Die S-BPM Methode verwendet zwei Ebenen, um Prozesse zu beschreiben, 
das Subjekt Interaktionsdiagramm (SID: Subject Interaction Diagram) und das 
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Subjektverhaltensdiagramm (SBD: Subject Behavior Diagram). Die Interaktion zwi- 
schen den Subjekten wird in dem SID visualisiert, welches die ausgetauschten Nach- 
richten zwischen den beteiligten Parteien (Subjekten) beschreibt. Das SID stellt eine 
Prozessübersicht bereit und hilft, die Rolle eines Subjekts im Gesamtprozess zu identi- 
fizieren. 

Das Subjektverhaltensdiagramm beschreibt die einzelnen Prozessschritte eines 
beteiligten Probanden für dessen Rolle im Prozess. Das Verhalten eines Subjekts wird 
beschrieben durch drei unterschiedliche Aktionen (die sogenannten „Zustände“ in 
S-BPM), die es durchführt: „Senden“, „Empfangen“, und Ausführen einer internen Auf- 
gabe („Funktion“). Da der für einen Prozessakteur relevante Teil eines Prozesses innerhalb 
des jeweiligen Subjekts gekapselt ist, repräsentiert jedes SBD einen eigenständigen Han- 
delnden innerhalb des Prozesses. Es ist nicht notwendig, den gesamten Prozess auf einmal 
oder in einer strikten Sequenz zu modellieren, z. B. wenn Informationen fehlen oder nicht 
verfügbar sind, oder ein Teil des Prozesses für die Untersuchung nicht relevant ist. 


Detaillierte Modellierung mit S-BPM Die S-BPM-Notation besteht aus fünf Symbolen, 
die durch ihre Bedeutung und nicht durch die Form definiert sind, obwohl Empfehlungen 
in der Literatur existieren. Zwei Symbole werden für das SID verwendet, um ein Subjekt 
bzw. Handelnden (z. B. eine rechteckige Form) und die Wechselwirkung (z. B. einen 
Pfeil) darzustellen, und drei Symbole für das SBD, um jeden einzelnen Zustandstyp 
(Senden, Empfangen, Funktion) darzustellen (am häufigsten rechteckige Formen in ver- 
schiedenen Farben). 

Ein Vorteil der beiden Ebenen und einer solchen einfachen Modellierungsnotation ist 
die Möglichkeit, Prozesse gleichzeitig in einem Top-Down- und/oder Bottom-Up-Ansatz 
zu modellieren, wobei die traditionell getrennten Bereiche Geschäftsprozessmanagement 
und Lean Production [8] in Abhängigkeit von den geforderten und unterschiedlichen 
Anforderungen zusammengeführt werden, je nach verfügbarer Detailtiefe der Informa- 
tionen. Obwohl es für die Modellierung von S-BPM dedizierte Softwarelösungen gibt, 
haben wir unsere eigene MS Visio-Vorlage verwendet. Dies ermöglichte es uns, uns 
sofort auf die Modellierung und Analyse der Prozesse zu konzentrieren, ohne Ressourcen 
und Zeit in die Anwendung einer externen technischen Lösung zu investieren — ein häu- 
figer Fehler in vielen Unternehmen, wenn Prozessmodellierung implementiert wird [9]. 

Durch detailliertere persönliche Interviews erstellten wir ein Modell der ersten Ebene 
des Prozesses, das SID. Das daraus resultierende Prozessmodell der Ist-Situation ergab, 
dass der Logistik- und Produktionsprozess wie erwartet sehr komplex ist. Ungefähr 
40 involvierte Subjekte verteilten sich auf die Produktion, Produktionssteuerung und 
Logistik aller drei Produkte in beiden Fabriken. Die endgültige Version des resultieren- 
den Ist-SID und die verwendete Notation sind in Abb. 7.4 zu sehen. Das SID zeigt die 
allgemeine Kommunikationsstruktur des Prozesses und welche Subjekte miteinander 
welche Nachrichten austauschen. Die konkreten Namen der Subjekte oder der Inhalt der 
ausgetauschten Nachrichten sind für das weitere Verständnis der durchgeführten Maß- 
nahmen nicht relevant. 
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Abb. 7.4 Kommunikationsstruktur (Subject Interaction Diagram) der Produktion und des Bestell- 
prozesses 


Modellbildung und -analyse Die rechteckigen Formen repräsentieren die verschiedenen 
Subjekte, die an dem Prozess beteiligt sind, und die Pfeile repräsentieren die Nachrichten 
zwischen den Subjekten. Um zwischen den beiden Fabriken zu unterscheiden, haben 
wir die entsprechenden Subjekte farbig in Grün für Fabrik A und Orange für Fabrik B 
gekennzeichnet. Außerdem haben wir die Subjekte, welche SAP®-Systeme darstellen 
mittels Schraffur gekennzeichnet, um die bereits digitalen Teile des bestehenden Prozes- 
ses hervorzuheben. 

Obwohl von beiden Werken dasselbe ERP-System verwendet wird, teilen wir es 
für eine strukturiertere Visualisierung entsprechend den jeweiligen Abteilungen auf 
(SAP®-System A, SAP®-System B und SAP®-System A Disposition). 


Identifikation von Optimierungsmöglichkeiten Aufgrund der Anzahl der involvierten 
Subjekte und der Komplexität des gesamten Prozesses wäre es nicht praktikabel 
gewesen, alle Subjektverhalten ohne einen definierten Rahmen für unsere nächsten 
Schritte zu erheben und zu modellieren. 
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Um einen solchen Rahmen zu definieren, haben wir das nun vorhandene SID ver- 
wendet, um die Hauptknoten und Engpässe im Prozess für das entsprechende Produkt zu 
identifizieren und zu analysieren (Abb. 7.5). 


Weiter Prozessmodellierung Ist-Analyse der IT-Unterstützung Der auffälligste Teil 
des Prozesses war die Auftragsabwicklung selbst. Die Abarbeitung der Bestellung 
von Produkt 1 durch Fabrik A, die Auftragsabwicklung und die Beschaffung von Pro- 
dukt 2 durch Fabrik B sowie die Produktion von Produkt 3 in Fabrik A beschäftigte bis 
zu 12 Subjekte (3 SAP®-Systeme und 9 Personen) und nahm bis zu 15 Arbeitstage in 
Anspruch. Außerdem wurden nur 65 % des Produkts 2 pünktlich fertiggestellt, weil die 
Auftragsabwicklung zu lange dauerte und die Aufträge im Produktionszentrum zu spät 
eingingen (ca. 95 % aller Aufträge). Dies hatte direkte Auswirkungen auf die Produktion 
von Produkt 1 und auf die Prozessstabilität. Die Lieferzeiten konnten nur mit viel Auf- 
wand in der Produktion eingehalten werden. 

Wir haben uns entschieden, uns auf diesen Materialbeschaffungsprozess zu konzen- 
trieren, da der Prozess selbst relativ zur Komplexität der bereitgestellten Komponenten 
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Abb. 7.5 Zusammenhang der Kommunikationsstruktur mit den jeweiligen Produkten 
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(Produkt 3) sehr komplex und zeitaufwendig ist. Wir haben den Umfang unserer Prozess- 
erhebung wie folgt definiert: 


e Der Fokus liegt auf den Logistikabteilungen von Fabrik A und Fabrik B. Dazu gehört 
auch die Produktion von Produkt 3 in der Fabrik A, da diese organisatorisch direkt in 
die Logistik integriert ist und somit Teil des Prozesses und der Produktion von Produkt 
2 in Fabrik B ist. 

e Die Materialbeschaffung in Fabrik A und die tatsächliche Montage von Produkt 1 in 
Fabrik A sind nicht mehr Teil der Erhebung (siehe Abb. 7.5 für eine Visualisierung 
des Prozesses und der entsprechenden Produkte). 


Validierung des Prozessmodells Wir untersuchten die relevanten Prozessschritte, indem 
wir die involvierten Mitarbeiter in Einzelinterviews befragten, die Mitarbeiter während 
des Prozesses begleiteten, und gleichzeitig für die Interviewpartner sichtbar die Subjekt- 
verhaltensdiagramme modellierten. So konnten wir den Prozessverlauf für Produkt 3 
(siehe Pfeile in Abb. 7.6) detailliert beschreiben, detaillierte Informationen über das 


Abb. 7.6 Kommunikationsstruktur (SID) des Prozesses für die Produktion von Produkt 3 
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SAP®-ERP-System und die verwendeten Transaktionen dokumentieren und den Inter- 
viewpartnern ermöglichen, die Prozessmodellierung direkt zu begleiten und das Modell 
verifizieren. 


Identifikation von Optimierungspotenzialen auf der Basis des Ist-Modells Nachdem die 
SAP®-Transaktionen in dem SID und dem SBD klar beschrieben wurden und einem 
Dummy-Auftrag durch das System gefolgt wurde, haben wir die verschiedenen Schritte 
des SAP®-Systems spezifiziert. Dies erlaubte es uns, zwischen automatisierten und 
manuellen Schritten zu unterscheiden, das überprüfte Prozessmodell zu verifizieren, und 
die tatsächlichen Prozessdurchlaufzeiten zu dokumentieren. Für das SBD verwendeten 
wir rechteckige Formen und verschiedene Farben, um die drei Zustände darzustellen; 
Rot für den Zustand „Senden“, Grün für den Zustand „Empfangen“ und Gelb für den 
Zustand „Funktion“ (siehe Abb. 7.7). 

Abb. 7.7 visualisiert das Prozessverhalten eines Mitarbeiters, der die Bearbeitung von 
Fertigungsaufträgen in Fabrik B abwickelt. Dieser Mitarbeiter prüft, ob Produktions- 
pläne für geplante Fertigungsaufträge vorliegen. Anschließend werden alle geplanten 
Produktionsaufträge mit verfügbaren Produktionsplänen nach einem definierten Regel- 
werk zusammengefasst und zur Produktion freigegeben. Die Mitarbeiter erledigen dies 
manuell für jeden Produktionsauftrag, bei mehreren tausend Bestellungen pro Tag. Pro- 
dukt 3 allein verursacht insgesamt eine Arbeitsbelastung von ca. 7 h pro Tag. 


Optimierung des Prozessmodells Der Gesamtaufwand für die gesamte Erhebung, alle 
Interviews und die Zeit, die für die Vervollständigung und Überprüfung der Prozess- 
modelle benötigt wurde, betrug ca. 200 geleistete Arbeitsstunden. Dies ist ein relativ 
geringer Aufwand im Vergleich zu anderen Prozessoptimierungsprojekten angesichts der 
Komplexität der Prozessmodelle und der untersuchten Tiefe bzw. Details. 


Organisatorische Implementierung Mit dem nun vorhandenen detaillierten Wissen 
über die involvierten Subjekte haben wir anhand der gesammelten Daten und der im 
SAP®-System dokumentierten Daten (Bestellzeiten, Lieferzeiten etc.) einen Zeitplan für 
den Prozess erstellt. Dieser Zeitplan beinhaltet alle Organisations- und Produktionsschritte 
und deren jeweilige Durchlaufzeiten. Beispielsweise betrug die Durchlaufzeit für eine der 
Produkt 1-Varianten, von der Bestellannahme in Fabrik B bis zur Lieferung des fertigen 
Produkts 1 an die Montagelinie in Fabrik A, ungefähr 30 Arbeitstage (vgl. Abb. 7.8). 


Prozessoptimierungen In Zusammenarbeit mit den Mitarbeitern wurden die bestehenden 
Arbeitspläne überarbeitet, aktualisiert und verbessert. Dies führte zu verkürzten Durch- 
laufzeiten für die Arbeitsschritte sowie zu einer reduzierten Anzahl von Arbeitsschritten 
durch die Zusammenführung bestehender Schritte. In diesem Fall bedeutet eine reduzierte 
Anzahl von Arbeitsschritten weniger Subjekte als auch weniger Verhaltenszustände. Wäh- 
rend der Analyse haben wir mehrere ähnliche Prozessschritte identifiziert, die in Fabrik A 
und Fabrik B unterschiedlich durchgeführt wurden. In einer Fabrik wurden notwendige 
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Abb. 7.7 Beispiel für eine Verhaltensbeschreibung eines Mitarbeiters 


Prozessschritte manuell ausgeführt, jedoch automatisch vom SAP®-System in der ande- 
ren Fabrik ausgeführt. 

Darüber hinaus wurden vorhandene automatisierte SAP®-Batch-Jobs unterbrochen, da 
die erforderliche manuelle Eingabe zwischen den Jobs fehlte. Diese Jobs wurden zu zwei 
definierten Zeiten während des Arbeitstages eingeplant. Wenn zu diesem Zeitpunkt die 
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Abb. 7.8 Zeitverbrauch im Ausgangsprozess 


manuelle Eingabe fehlte, musste die gesamte Bestellung bis zu einem gesamten Arbeits- 
tag warten. Dies konnte bei jeder Bestellung mehrmals für verschiedene Jobs geschehen, 
was letztendlich zu einer Verzögerung von mehreren Arbeitstagen führen konnte. 


IT-Implementierung Die beschriebenen Subjekte lieferten präzise definierte Prozesse, 
die alle relevanten Prozessschritte im SAP®-System beschreiben, alle erforderlichen 
SAP®-Transaktionen, wer diese Transaktionen ausführt, sowie die Interaktionen zwi- 
schen System und Mitarbeitern. Aufgrund dieser detaillierten Prozessdokumentation 
konnte unsere [T-Abteilung das relevante Subjektverhalten direkt implementieren, um 
neue standardisierte, digitalisierte und automatisierte Prozesse zu erstellen, Prozess- 
schritte zu überarbeiten und den Verarbeitungsplan von bestehenden Batch-Jobs für 
beide Fabriken zu rationalisieren. 

Dies beinhaltete Schritte wie Auftragsannahme, Auftragserfassung, Auftrags- 
eröffnung, Auftragsfreigabe in beiden Werken und Lieferung der Fertigungspapiere an 
die Produktion. Die automatische Bestellabwicklung ermöglichte die auftragsbezogene 
und zeitnahe Bearbeitung von Produkt 3 in der Fabrik A, was uns wiederum die Ein- 
führung von KANBAN-Beständen mit definierten kritischen Teilen, die Reduzierung des 
Lagerbestands unkritischer Teile, und den Versand von extern gekauften Teilen direkt in 
die Fertigung ermöglichte. 
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Eines der erreichten Ergebnisse war eine neue Lagerstrategie und eine Neubewertung 
des Lagerbestandes. Dies ermöglichte, den gesamten Lagerbestand zu überarbeiten und 
ein KANBAN-System für kritische Teile von Produkt 3 zu implementieren. Der neu 
geschaffene KANBAN-Bestand und der höhere Wert der betroffenen Teile führten zu 
einer Steigerung des gebundenen Kapitals um ca. 209 %. Dies hatte jedoch nur minima- 
len Einfluss auf den bestehenden Lagerwert von insgesamt etwa 10.000 €. Die neue Stra- 
tegie erhöhte die Verfügbarkeit und reduzierte die Lieferzeiten für alle zugekauften Teile. 

Die Unterbrechungen bei der Herstellung von Produkt 2 aufgrund fehlender Teile 
konnten ursprünglich bis zu 15 Arbeitstage dauern. Nach den Änderungen waren alle 
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benötigten Komponenten innerhalb eines Arbeitstages entweder direkt vor Ort oder über 
den Sicherheitsbestand beim Lieferanten verfügbar. Damit konnten eine signifikante Ver- 
besserung der Prozessstabilität sowie eine Reduktion des Umlaufbestandes bei einem 
vergleichsweise geringen Anstieg des Lagerbestands erreicht werden. 

Die Wertstromanalyse ist in unserem Unternehmen ein etabliertes Werkzeug zur 
Analyse von Produktionsprozessen. Obwohl die Literatur [10, 11] und unsere externen 
Berater oft die Möglichkeit der WSA hervorgehoben haben, nicht nur Materialflüsse, 
sondern auch Informationsflüsse zu beschreiben, wurden unsere Erwartungen nicht 
erfüllt, als wir versuchten, dies zu dokumentieren und zu visualisieren. Wenn die meisten 
relevanten Informationen verfügbar sind, können die administrativen Prozesse und der 
Informationsfluss mit einem Wertstrommodell beschrieben werden. 


Erfahrungen mit Modellierungssprachen Aufgrund unserer Erfahrungen eignet sich ein 
WSM jedoch nicht für eine Darstellung des Informationsflusses mit teilweise abstrak- 
ten Informationen. S-BPM bot uns eine einfach zu lernende Modellierungsnotation, die 
dennoch sehr genaue und detaillierte Prozessmodelle liefern kann. Die involvierten Mit- 
arbeiter konnten die S-BPM-Notation selbstständig verstehen, lesen und richtig inter- 
pretieren und begannen, ihre eigenen Prozessmodelle (das Subjektverhalten) ohne den 
Input der Methodenspezialisten zu verifizieren. Dies führte zu einer hohen Akzeptanz der 
Prozesserhebung und der folgenden Veränderungen im Prozess, da die Mitarbeiter direkt 
an der Dokumentation und den Optimierungsschritten beteiligt waren. 


Betrieb und Monitoring Die vorgenommene Umstrukturierung und Digitalisierung 
zuvor manueller Prozessschritte führte zu einem standardisierten Prozess und einer 
Reduktion der beteiligten Subjekte von 12 auf 8 (siehe Abb. 7.9). Weniger Subjekte 
bedeuten weniger Schnittstellen im Prozess, was wiederum die Prozesskomplexität redu- 
ziert und die Prozessstabilität und -transparenz erhöht. Darüber hinaus wurden die Mit- 
arbeiter von zeitraubenden und sich wiederholenden Aufgaben befreit. 

Der erhöhte Digitalisierungsgrad und der neue geplante Ablauf führten zu einer neuen 
Prozessdurchlaufzeit von 2 Tagen (von ursprünglichen 5-10 Tagen) für die Auftragsab- 
wicklung. Aufgrund des detaillierten und klar definierten Prozesses konnte unsere IT- 
Abteilung die Prozessänderungen in der bestehenden Systemumgebung innerhalb von 
nur 3 Arbeitstagen umsetzen. Der Produktions- und Versandprozess für Produkt 3 konnte 
auf 3 Tage reduziert werden, und zwar von ursprünglichen 5-6 Tagen. Dies bedeutet, 
dass wir die Gesamtdurchlaufzeit von 11-15 Arbeitstagen von Produkt 3 um 87 % auf 
2 Arbeitstage reduzieren konnten. Diese Änderungen führten zu einer erhöhten Liefer- 
termintreue für Produkt 3: Die Liefertreue stieg bereits vier Wochen nach der Umsetzung 
auf 89 % und nach einem Jahr auf 97 %. 


Gemessene Kennzahlen Der relativ hohe Zeitaufwand für die Auftragsabwicklung 
für Produkt 3 in der Anfangsphase führte dazu, dass die meisten Aufträge in der Fab- 
rik A zu spät oder sehr kurzfristig ankamen. Die neu geschaffenen automatisierten 
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Abb. 7.9 Kommunikationsstruktur des aktualisierten Prozesses für Produkt 3 


SAP®-Prozesse führten zu einer schnelleren Bearbeitung von Bestellungen der Fabrik 
A innerhalb der Abteilungen von Fabrik B. Dies hatte eine kürzere Bestellzeit für Pro- 
dukt 3 und einen früheren Produktionsstart anderer Komponenten, die für Produkt 2 
erforderlich waren, zur Folge. Das Ergebnis war eine Reduktion von anfänglich 95 % 
der Bestellungen, die zu spät registriert wurden, auf nur 12 %, wodurch wiederum die 
Prozessstabilität und Prozessqualität stark erhöht wurden und der Bedarf an Fehlersuche 
in beiden Fabriken reduziert werden konnte. Die Gesamtdurchlaufzeit des Produktions- 
und Bestellprozesses von Produkt 2 konnte um 7 Arbeitstage (ca. 38 %) verkürzt werden, 
von 19-23 Tagen auf 12-14 Tage. 

Die Umwandlung von manueller Arbeit in automatisierte, digitalisierte Prozesse im 
SAP®-System führte zu einer reduzierten Arbeitsbelastung der beteiligten Mitarbeiter 
von 5-6 h auf bis zu einer Stunde pro Tag. Die Mitarbeiter mussten nun die Bestellungen 
nur mehr für spezielle Komponenten bzw. Sonderfälle, die nicht vom SAP®-System 
abgedeckt werden konnten, manuell bearbeiten. Die Auswirkungen dieser Änderungen 
addieren sich zu einer kalkulierten Prozesskostenreduktion von rd. 65.000 € pro Jahr. 
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Die implementierten Verbesserungen und entsprechende Änderungen auf der Prozess- 
ebene reduzierten die Durchlaufzeiten für Produkt 2 und 3 und führten zu einer ver- 
kürzten Gesamtdurchlaufzeit für Produkt 1 von 26 bis 33 Arbeitstagen auf 18 bis 20 
Arbeitstage. Dies entspricht einer Gesamtreduktion von ungefähr 60 % für den gesamten 
Bestell- und Produktionsprozess (vgl. Abb. 7.10 und 7.11). 


Abschließende Analyse der erreichten Ergebnisse Wir konnten nicht nur das gesteckte 
Ziel einer 30 %igen Durchzeitverkürzung erreichen, sondern konnten diese Reduktion 
durch Digitalisierung und Automatisierung der Prozessschritte und des entsprechenden 
Informationsflusses mehr als verdoppeln. Dies führte in weiterer Folge zu einer Reduk- 
tion des Umlaufbestandes mit einem Gesamtwert von mehreren hunderttausend Euro 
über den gesamten Prozess. 

Unsere Ergebnisse zeigen, dass es möglich ist, durch die Optimierung und Digitali- 
sierung des Informationsflusses die Durchlaufzeit und die manuelle Arbeitsbelastung 
deutlich zu reduzieren. Der erhöhte Digitalisierungsgrad und die damit verbundene 
Prozesstransparenz kann dazu beitragen, weitere Verbesserungen zu erreichen und die 
Prozesse in zukünftigen Analysen besser zu verstehen [12]. Obwohl die Einführung 
spezialisierter S-BPM-Tools bewusst vermieden wurde, könnte deren Einführung dank 
der S-BPM-Methodik die Grundlage für eine noch umfassendere Digitalisierung der 
bestehenden Prozesse bieten. Die S-BPM-Methode und unterstützende Modellierungs- 
werkzeuge ermöglichen eine direkte Transformation von Prozessmodellen in laufende 
Prozesse [4]. So könnte der Aufwand für die zukünftige Digitalisierung von Prozessen 
deutlich reduziert werden. 


Abb. 7.11 Zeitbedarf im überarbeiteten Prozess 
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